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.
On Tue, 23 Oct 2018 at 22:21, Joseph Myers <jos...@codesourcery.com> wrote:
>
> 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
> jos...@codesourcery.com
