On Mon, Mar 11, 2024 at 8:46 AM Richard Biener <richard.guent...@gmail.com> wrote: > > On Sun, Mar 10, 2024 at 10:09 PM Jeff Law <j...@ventanamicro.com> wrote: > > > > > > > > On 3/10/24 3:05 PM, Andrew Pinski wrote: > > > On Sun, Mar 10, 2024 at 2:04 PM Jeff Law <j...@ventanamicro.com> wrote: > > >> > > >> Here's a potential approach to fixing PR92539, a P2 -Warray-bounds false > > >> positive triggered by loop unrolling. > > >> > > >> As I speculated a couple years ago, we could eliminate the comparisons > > >> against bogus pointers. Consider: > > >> > > >>> <bb 8> [local count: 30530247]: > > >>> if (last_12 != &MEM <const char> [(void *)"aa" + 3B]) > > >>> goto <bb 9>; [54.59%] > > >>> else > > >>> goto <bb 12>; [45.41%] > > >> > > >> > > >> That's a valid comparison as ISO allows us to generate, but not > > >> dereference, a pointer one element past the end of the object. > > >> > > >> But +4B is a bogus pointer. So given an EQ comparison against that > > >> pointer we could always return false and for NE always return true. > > >> > > >> VRP and DOM seem to be the most natural choices for this kind of > > >> optimization on the surface. However DOM is actually not viable because > > >> the out-of-bounds pointer warning pass is run at the end of VRP. So > > >> we've got to take care of this prior to the end of VRP. > > >> > > >> > > >> > > >> I haven't done a bootstrap or regression test with this. But if it > > >> looks reasonable I can certainly push on it further. I have confirmed it > > >> does eliminate the tests and shuts up the bogus warning. > > >> > > >> The downside is this would also shut up valid warnings if user code did > > >> this kind of test. > > >> > > >> Comments/Suggestions? > > > > > > ENOPATCH > > Yea, realized it as I pushed the send button. Then t-bird crashed, > > repeatedly. > > > > Attached this time.. > > There's fold-const.cc:address_compare and > tree-ssa-alias.cc:ptrs_compare_unequal, > both eventually used by match.pd that could see this change, the former > already > special-cases STRING_CST to some extent. > > I'll note that the value we simplify such comparison to is arbitrary. > Doing such > simplification directly (as opposed to only benefit from its > undefinedness indirectly) > always gives me the creeps ;) > > IMO we should instead simplify the condition to __builtin_unreachable/trap aka > isolate the path as unreachable.
I see for the testcase we get to see the invalid compares in forwprop while the diagnostic happens in VRP which is way before path isolation. IMO it's sensible to make forwprop do the path isolation, but this is probably nothing for stage4. Scheduling another pass isolation path before array-bound diagnostics might also make sense (it would be nice to dis-entangle -Warray-bounds from VRP itself) Richard. > Richard. > > > jeff > >
