Re: About GSOC.

[Joseph Myers <joseph@codesourcery.com>]

On Tue, 23 Oct 2018, Martin Jambor wrote:

> 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).

> think this would be a good (part of) a GSoC project next year?

If a suitable mentor is available for it next year.

> > 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.

> > 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.

> > 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.)

> > 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@codesourcery.com