This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/32390] tree-ssa-math-opts.c performs too many IL scans
- From: "ubizjak at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 18 Jun 2007 17:40:08 -0000
- Subject: [Bug tree-optimization/32390] tree-ssa-math-opts.c performs too many IL scans
- References: <bug-32390-91@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #3 from ubizjak at gmail dot com 2007-06-18 17:40 -------
(In reply to comment #2)
> We need a better explanation than this. Uros agreed to summarize the
> IRC discussion to close this issue. It'd be useful if we keep that same
> discussion on the source code itself.
The need for separate IL passes could be explained by:
We have reciprocal pass (in fact CSE recip pass) that CSEs 1.0/z from x/z, y/z,
.../z. This is done by scanning function for RDIV_EXPR, where denominator (z)
is the same. If 1.0/func() -> rfunc() conversion is done before recip pass, we
loose the ability to scan for RDIV_EXPRs and the ability to CSE the division.
By putting 1.0/func()->rfunc() after recip pass, we simply run another scan for
RDIV_EXPRs with function as their argument. Note that we already CSE'd
1.0/func(), so the conversion into rfunc() is trivial. This is the reason why
function recip pass needs to run after recip (aka CSE recip) pass.
Next convesion is sqrt(a/b) -> rsqrt(b/a) conversion that runs after rfunc
recip pass as a separate pass (so, in the function granulartiy). If this pass
is run together or before rfunc pass, then rsqrt pass would convert expressions
like 1.0/sqrt(a/b) into 1.0/rsqrt(b/a). There is no point for rfunc pass (that
would follow) to convert this to sqrt(b/a).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32390