This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Simplify builtins when result ignored.
- From: Roger Sayle <roger at www dot eyesopen dot com>
- To: Zack Weinberg <zack at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sun, 13 Apr 2003 12:04:55 -0600 (MDT)
- Subject: Re: [PATCH] Simplify builtins when result ignored.
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.
In conclusion, I thought it best to keep these tricks with their
RTL expanders.
> Also it might be a good idea to do it at "fold" time as well, which
> would avoid even more work.
This is good suggestion, though it could be considered to overlap with
the tree-ssa stuff a bit. I'll look into a generic method of eliminating
pure and const functions in fold. However, like the strlen of a constant
string hunk, we'll probably want this code in both places as well.
> > Whilst there, I also added the expansion-time optimization of strlen
> > for constant strings. This is typically handled by "fold", but
> > performing the check in expand_builtin_strlen provides both a good
> > pedagogical example and reduces the dependencies between GCC passes.
> > For example, if tree-SSA or a language front-end didn't call "fold"
> > on an expression before RTL expansion.
>
> This piece is approved for mainline -- but only as a separate patch
> from the other changes.
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.
Roger
--