About GSOC.

[Tejas Joshi]

Hello.
I reached asking about GCC GSoC project about adding and
folding functions
like roundeven. I could not apply for the idea this year but
interested in the peoject and
really hoping it would be carry forwarded. Since I've been studying
source code and about the project, I think working on this from now
would give me some heads up and hands on with the source code.

I did study <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1778.pdf>.
It does tell that roundeven rounds its argument to nearest integral
ties to even (least significant bit 0) returning integral value
provided that the resulting value is exact.
So, for the start, I'd be implementing this functionality for roundeven.
As ita said in earlier mails that, similar functions like
real_ceil are implemented
in real.c and are used in fold-const-call.c.
Roundeven might be implemented in similar way. Is it built-in
(internal) function means not to be exposed to end-user?
Studying some functions like real_ceil, there are call checks
(flag_errno_math) so I believe similar would be needed for roundeven.

In real.c where real_ceil is implemented, there are function calls
(and implementations) like do_fix_trunc which also then call functions
like decimal_do_dix_trunc (maybe the main functionality of
do_fix_trunc?, other are just checks, like NaN or qNaN). I did not
understand these functions really and what do they do. Also I did not
understand the structure of REAL_VALUE_TYPE (r->cl and etc?)

Also when does the real.c and fold-const-call.c comes in picture in
the flow of GCC (Is it for GIMPLE level instruction selection (gimple
stmnt to corresponding rtl instruction))?
Thanks.

Regards,
-Tejas

[Martin Jambor]

Hi Joseph,

this seems related to your proposal GSoC proposal in the beginning
of this year. Do you have any comments about Tejas's idea? Do you
think this would be a good (part of) a GSoC project next year?

Thanks a lot,

Martin

Post by Tejas Joshi
Hello.
I reached asking about GCC GSoC project about adding and
folding functions
like roundeven. I could not apply for the idea this year but
interested in the peoject and
really hoping it would be carry forwarded. Since I've been studying
source code and about the project, I think working on this from now
would give me some heads up and hands on with the source code.
I did study <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1778.pdf>.
It does tell that roundeven rounds its argument to nearest integral
ties to even (least significant bit 0) returning integral value
provided that the resulting value is exact.
So, for the start, I'd be implementing this functionality for roundeven.
As ita said in earlier mails that, similar functions like
real_ceil are implemented
in real.c and are used in fold-const-call.c.
Roundeven might be implemented in similar way. Is it built-in
(internal) function means not to be exposed to end-user?
Studying some functions like real_ceil, there are call checks
(flag_errno_math) so I believe similar would be needed for roundeven.
In real.c where real_ceil is implemented, there are function calls
(and implementations) like do_fix_trunc which also then call functions
like decimal_do_dix_trunc (maybe the main functionality of
do_fix_trunc?, other are just checks, like NaN or qNaN). I did not
understand these functions really and what do they do. Also I did not
understand the structure of REAL_VALUE_TYPE (r->cl and etc?)
Also when does the real.c and fold-const-call.c comes in picture in
the flow of GCC (Is it for GIMPLE level instruction selection (gimple
stmnt to corresponding rtl instruction))?
Thanks.
Regards,
-Tejas

[Joseph Myers]

Post by Martin Jambor
Hi Joseph,
this seems related to your proposal GSoC proposal in the beginning
of this year. Do you have any comments about Tejas's idea? Do you

My proposal was designed so that it would be possible to do some small
piece, that is useful by itself, and so learn about some parts of the
compiler, and then go onto another piece, and so learn about other parts
of the compiler - as there are lots of separate pieces that are related,
but each useful by itself as a contribution to GCC. The parts Tejas
refers to are good pieces to be looking at for one such piece (roundeven
folding for constant arguments) (along with e.g. builtins.def to define
the built-in functions).

Post by Martin Jambor
think this would be a good (part of) a GSoC project next year?

If a suitable mentor is available for it next year.

Post by Martin Jambor

Post by Tejas Joshi
It does tell that roundeven rounds its argument to nearest integral
ties to even (least significant bit 0) returning integral value
provided that the resulting value is exact.
So, for the start, I'd be implementing this functionality for roundeven.
As ita said in earlier mails that, similar functions like
real_ceil are implemented
in real.c and are used in fold-const-call.c.
Roundeven might be implemented in similar way. Is it built-in
(internal) function means not to be exposed to end-user?
Studying some functions like real_ceil, there are call checks
(flag_errno_math) so I believe similar would be needed for roundeven.

The expectation for this part of the project would be that calls to both
__builtin_roundeven and roundeven (and similar functions with f, l, f128
etc. suffixes) would be folded when the arguments are constants (both
direct calls with constants such as roundeven (2.5), and cases where
GIMPLE optimization passes propagate a constant into the call, such as
"double d = 2.5; return roundeven (d);"). This of course involves various
internal functions in the compiler to implement that.

If you compile code such as

double
f (void)
{
double d = 2.5;
return ceil (d);
}

with -O2 -S -fdump-tree-all, you can look at the generated dump files to
see which optimization pass the folding into constant 3.0 occurs in.
Looking at such dumps is an important way of finding your way around the
optimization passes in the compiler.

Post by Martin Jambor

Post by Tejas Joshi
In real.c where real_ceil is implemented, there are function calls
(and implementations) like do_fix_trunc which also then call functions
like decimal_do_dix_trunc (maybe the main functionality of
do_fix_trunc?, other are just checks, like NaN or qNaN). I did not

You can ignore any cases for decimal floating-point values (do gcc_assert
(!r->decimal)), given that the project does not involve adding any decimal
floating-point built-in functions. That means you should instead
understand REAL_EXP and the significands of floating-point values, and
what functions such as clear_significand_below and test_significand_bit
do, because you'll need to write your own logic like that in do_fix_trunc,
with appropriate cases for whether the bits with values 0.5 and below form
part of the significand.

Post by Martin Jambor

Post by Tejas Joshi
understand these functions really and what do they do. Also I did not
understand the structure of REAL_VALUE_TYPE (r->cl and etc?)

I suggest looking more closely at the definition of cl in real.h. It's
true that it doesn't have a comment specifying its semantics directly, but
the /* ENUM_BITFIELD (real_value_class) */ should give a strong hint,
along with the values that are stored in that field. By looking at how
all the fields in real_value are used, you should be able to deduce their
semantics, and then send a GCC patch that adds a comment to each field
with a more detailed description of its semantics, which would be a useful
contribution by itself to help people reading real.c code in future.

(struct real_format has more detailed comments on some of the fields. I
suggest using those as a model for the comments that ought to be written
for the fields of struct real_value.)

Post by Martin Jambor

Post by Tejas Joshi
Also when does the real.c and fold-const-call.c comes in picture in
the flow of GCC (Is it for GIMPLE level instruction selection (gimple
stmnt to corresponding rtl instruction))?

The code you're looking at is used in GIMPLE optimizations, and possibly
folding before GIMPLE.

Converting roundeven calls with non-constant arguments to appropriate
instructions (for processors that have them, e.g. x86 with SSE 4.1 and
later) is also useful, and will involve changes to optabs.def,
internal-fn.def and target .md files. But I'd advise doing one
self-contained piece first (such as the folding for constant arguments)
before moving on to others (such as generating appropriate instructions
for the case of non-constant arguments).

[Tejas Joshi]

About roundeven, there might be need to add case to
expand_builtin_int_roundingfn similar to
ceil, for expansion.
But how is round() expanded since there's no
entry for it in expand_builtin_int_roundingfn ?

Also, is it right to have an added case for roundeven in convert.c
along CASE_FLT_FN (BUILT_IN_ROUND)
in convert_to_integer_1?

Thanks.

Post by Joseph Myers

Post by Martin Jambor
Hi Joseph,
this seems related to your proposal GSoC proposal in the beginning
of this year. Do you have any comments about Tejas's idea? Do you

My proposal was designed so that it would be possible to do some small
piece, that is useful by itself, and so learn about some parts of the
compiler, and then go onto another piece, and so learn about other parts
of the compiler - as there are lots of separate pieces that are related,
but each useful by itself as a contribution to GCC. The parts Tejas
refers to are good pieces to be looking at for one such piece (roundeven
folding for constant arguments) (along with e.g. builtins.def to define
the built-in functions).

Post by Martin Jambor
think this would be a good (part of) a GSoC project next year?

If a suitable mentor is available for it next year.

Post by Martin Jambor

Post by Tejas Joshi
It does tell that roundeven rounds its argument to nearest integral
ties to even (least significant bit 0) returning integral value
provided that the resulting value is exact.
So, for the start, I'd be implementing this functionality for roundeven.
As ita said in earlier mails that, similar functions like
real_ceil are implemented
in real.c and are used in fold-const-call.c.
Roundeven might be implemented in similar way. Is it built-in
(internal) function means not to be exposed to end-user?
Studying some functions like real_ceil, there are call checks
(flag_errno_math) so I believe similar would be needed for roundeven.

The expectation for this part of the project would be that calls to both
__builtin_roundeven and roundeven (and similar functions with f, l, f128
etc. suffixes) would be folded when the arguments are constants (both
direct calls with constants such as roundeven (2.5), and cases where
GIMPLE optimization passes propagate a constant into the call, such as
"double d = 2.5; return roundeven (d);"). This of course involves various
internal functions in the compiler to implement that.
If you compile code such as
double
f (void)
{
double d = 2.5;
return ceil (d);
}
with -O2 -S -fdump-tree-all, you can look at the generated dump files to
see which optimization pass the folding into constant 3.0 occurs in.
Looking at such dumps is an important way of finding your way around the
optimization passes in the compiler.

Post by Martin Jambor

Post by Tejas Joshi
In real.c where real_ceil is implemented, there are function calls
(and implementations) like do_fix_trunc which also then call functions
like decimal_do_dix_trunc (maybe the main functionality of
do_fix_trunc?, other are just checks, like NaN or qNaN). I did not

You can ignore any cases for decimal floating-point values (do gcc_assert
(!r->decimal)), given that the project does not involve adding any decimal
floating-point built-in functions. That means you should instead
understand REAL_EXP and the significands of floating-point values, and
what functions such as clear_significand_below and test_significand_bit
do, because you'll need to write your own logic like that in do_fix_trunc,
with appropriate cases for whether the bits with values 0.5 and below form
part of the significand.

Post by Martin Jambor

Post by Tejas Joshi
understand these functions really and what do they do. Also I did not
understand the structure of REAL_VALUE_TYPE (r->cl and etc?)

I suggest looking more closely at the definition of cl in real.h. It's
true that it doesn't have a comment specifying its semantics directly, but
the /* ENUM_BITFIELD (real_value_class) */ should give a strong hint,
along with the values that are stored in that field. By looking at how
all the fields in real_value are used, you should be able to deduce their
semantics, and then send a GCC patch that adds a comment to each field
with a more detailed description of its semantics, which would be a useful
contribution by itself to help people reading real.c code in future.
(struct real_format has more detailed comments on some of the fields. I
suggest using those as a model for the comments that ought to be written
for the fields of struct real_value.)

Post by Martin Jambor

Post by Tejas Joshi
Also when does the real.c and fold-const-call.c comes in picture in
the flow of GCC (Is it for GIMPLE level instruction selection (gimple
stmnt to corresponding rtl instruction))?

The code you're looking at is used in GIMPLE optimizations, and possibly
folding before GIMPLE.
Converting roundeven calls with non-constant arguments to appropriate
instructions (for processors that have them, e.g. x86 with SSE 4.1 and
later) is also useful, and will involve changes to optabs.def,
internal-fn.def and target .md files. But I'd advise doing one
self-contained piece first (such as the folding for constant arguments)
before moving on to others (such as generating appropriate instructions
for the case of non-constant arguments).
--
Joseph S. Myers

[Joseph Myers]

Post by Tejas Joshi
About roundeven, there might be need to add case to
expand_builtin_int_roundingfn similar to
ceil, for expansion.
But how is round() expanded since there's no
entry for it in expand_builtin_int_roundingfn ?

Please see the comment above expand_builtin_int_roundingfn, and that above
expand_builtin_int_roundingfn_2, which handle different sets of functions.
Those functions are of no relevance to adding support for built-in
roundeven. (They might be of relevance to support for built-in fromfp
functions, depending on whether the detailed semantics allows
casts-to-integer of calls to other functions to be converted into calls to
the fromfp functions. But I don't think inventing __builtin_lroundeven
would be appropriate.)

Post by Tejas Joshi
Also, is it right to have an added case for roundeven in convert.c
along CASE_FLT_FN (BUILT_IN_ROUND)
in convert_to_integer_1?

Not until doing things with fromfp functions. There is no lroundeven (for
example) in TS 18661-1.