https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
Jeffrey A. Law <law at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |law at redhat dot com
--- Comment #33 from Jeffrey A. Law <law at redhat dot com> ---
Martin,
Richi's right. If you look at the .optimized dump you'll an huge number of
redundant conditionals.
We should compute b1 && b2 && b3 ... && b12 once and store the result into each
array element.
But the way we generate code for this can make it awful hard for the optimizers
to see the giant common subexpression.
If you look at the shape of the CFG and explore how to expose the various
redundancies, you'll see there's a cascading effect. ie, you expose some,
simplify and new opportunities appear.
Jump threading had the ability to do this many years ago. We kept iterating
DOM and forward jump threading until nothing changed. But that was very
expensive relative to what was gained and we removed the iteration code.
There's various things in the pipeline that might (or might not) help this
specific BZ over time. It's certainly in the back of my mind as we continue
the transition away from the forward equivalency table based jump threading to
the backward walking of the use-def chains.
The backwards approach holds a lot more promise to address this BZ. I'm
pretty sure the stuff planned would allow it to find all the threads in a
single pass. The question of cost of the backwards walking and block copying
necessary to isolate/expose the redundancies.
