On 12/16/2016 07:41 AM, Aldy Hernandez wrote:
BTW, I don't understand why we don't have auto_bitmap's, as we already
have auto_sbitmap's. I've implemented the former based on
auto_sbitmap's code we already have.
Trevor poked at it a bit. bitmaps are a bit more complex than sbitmaps
in terms of implementation details.
https://gcc.gnu.org/ml/gcc/2016-04/msg00013.html
But his suggestion was to first create auto_bitmap, then look to convert
to using that as opposed to his other approaches.
The attached patch fixes the bug without introducing any regressions.
I also tested the patch by compiling 242 .ii files with -O3. These were
gathered from a stage1 build with -save-temps. There is a slight time
degradation of 4 seconds within 27 minutes of user time:
tainted: 26:52
orig: 26:48
This was the average aggregate time of two runs compiling all 242 .ii
files. IMO, this looks reasonable. It is after all, -O3. Is it
acceptable?
Aldy
curr
commit 2310bcd0e2552a40ca1de354faf005ed3e9daf4e
Author: Aldy Hernandez <al...@redhat.com>
Date: Fri Dec 16 03:44:52 2016 -0500
PR tree-optimization/71691
* bitmap.h (class auto_bitmap): New.
* tree-ssa-loop-unswitch.c (ssa_maybe_undefined_value_p): New.
(tree_may_unswitch_on): Call ssa_maybe_undefined_value_p.
So I'm going to defer to Richi since he was reviewing my original
attempt in this space.
It probably doesn't matter in practice (when I looked at this I couldn't
get into the code in question with a -O3 bootstrap or with the
testsuite, just with the testcase in the BZ) but you might consider
handling an already visited node slightly differently.
If the the node was visited and resolved as undefined, then we would
have already exited the loop.
If the node was visited and resolved as defined, then we could just keep
processing other items on the the worklist.
The case where you want to conservatively return false is when you're
actively processing the name in question.
Jeff
