Re: [PATCH] Simplify builtins when result ignored (take 2)

[Jan Hubicka <jh at suse dot cz>]

> 
> On Sun, 20 Apr 2003, Jan Hubicka wrote:
> > > The following patch implements Zack's suggestion that the tests
> > > to avoid expanding "pure" and "const" built-in functions when
> > > the result is ignored should be done generically rather than on
> > > a builtin-by-builtin basis.
> >
> > Can't this be done for the calls in general (ie in expand_call)?
> 
> Hi Jan,
> 
> I'm currently looking into this.  The current tests are needed in
> expand_builtin as built-in functions are often expanded as inline
> instrinsics without ever reaching expand_call.  This may produce
> multiple basic blocks and complex insns that are difficult to
> pronounce dead by the RTL optimizers.

I see. Forgot about these.
> 
> Simple function calls to pure/const functions whose results aren't
> used are already considered dead by life analysis and cleaned up by
> later RTL passes.   Given that the majority of functions marked with

In general we would like to move away from libcall sequences and the
libcalls has some cost that can not be undone (like allocation of
outgoing argument area).  So once you do have the code in place I would
like to see it for generic calls as well.
> const and/or pure flags in a typical build will be GCC recognized
> system functions, these new checks in expand_builtin get us most of
> the potential "simple function call" benefit.
> 
> However, there's currently the possibility we may inline a pure/const
> function whose result isn't used.  This could obviously be improved.
> 
> 
> I'm also investigating similar simplifications at the tree-level,
> in fold perhaps near omit_one_operand, where we may also be able
> to remove useless pure/const function calls.  Applying this
> transformation at the tree-level may benefit the SSA folks.

Yes, that sounds like better plan.  Doing so inside fold_const would
catch both the builtins and calls.
> 
> Speaking of the SSA folks, one function that would help, is a
> tree-based version of "mark_constant_function", which would set
> DECL_IS_PURE or TREE_READONLY earlier.  Obviously, if we can tell
> that a function is pure, const, nothrow or noreturn at the tree
> level, it'll improve tree-inlining, DCE, alias analysis etc...
> My apologies if this functionality is already on tree-ssa branch.

With the unit-at-a-time patch we are mark most of the called functions
const/pure simply because we reorder the way they are emit, but porting
mark_constant_function into tree level is good idea anyway.
I beleive that the interprocedural alias analysis code already does
superset of what is needed so it should be easy to do too.
I hope to find time to familalize myself with the tree-ssa code more in
near future :)

Honza
> 
> Roger
> --