This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Simplify builtins when result ignored.


Roger Sayle <roger at www dot eyesopen dot com> writes:

> Hi Zack,
>> This is a good idea, but can't you make it a general optimization done
>> for all calls to functions with attribute pure or const, rather than
>> applying it individually in all these expanders?
>
> My concern was that the semantics of builtin functions may influence
> affect whether calls with volatile arguments and/or non-pure
> functions can be eliminated.  For example, atan(1.0), we don't know
> how to evaluate at compile-time, but we do know that it can't raise
> a floating point exception, i.e. sNaN, and won't set errno.  So its
> only because we know something about this function and its arguments
> that we can eliminate it if its result isn't used, even when its not
> pure.  Another example is pow(2.0,x) can never set errno, but that
> pow(-2.0,x) might.  There are similar tricks that can be played if
> only some of the arguments are volatile and the others are not.

I'm not sure I understand this argument 100% but it sounds like it
applies exclusively to functions that are *not* pure/const.  By
definition, pure/const functions have no effect beyond their return
value, so the 'don't bother calling' optimization should apply to them
universally.

It does make sense to apply this same optimization individually to
functions that aren't pure/const, when we can prove it's safe, and
that does go in the per-builtin expander routines -- but the functions
in your patch really do have no side effects.

> Thanks.  With twelve outstanding patches posted to the list, I'm
> trying to reduce (i) the backlog that needs to be reviewed and (ii)
> the conflicts caused by having multiple patches to the same hunk of
> code approved/rejected independently.  The regression testing alone
> would be combinatorially prohibitive.

Understood.  Could you send me a list of URLs to your outstanding
patches, off-list?  I will review whichever ones I can.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]