https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenth at gcc dot gnu.org
--- Comment #10 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Christophe Lyon from comment #9)
> (In reply to Aldy Hernandez from comment #7)
> > > then size ivopts-4.o:
> > > text data bss dec hex filename
> > > 38 0 0 38 26 ivopts-4.o
> > > where the testcase expects text <= 36
> >
> > Ohhhhh, this is an object size regression? This test seems very fragile.
> > Jump threading will alter code size, so any change in the threading rules
> > will likely have an effect on code size. I suggest you add
> > -fno-thread-jumps to the test and adjust the object-size test accordingly.
>
> I tried that, it doesn't change the generated code.
The difference from before the commit til now is that there was a threading
path that was valid but is now disallowed. So adding -fno-thread-jumps won't
have any effect since it won't cause the disallowed threading path to reappear.
What I'm saying is that the test should be calibrated to the new normal.
Of course, it could be that another pass should pick up the slack here, or that
the restriction is too strict. Richi, do you have some insight here?
At least for -Os -mthumb -mfloat-abi=hard -mfpu=neon -mtls-dialect=gnu
-mlibarch=armv7-a+mp+sec+neon-fp16 -march=armv7-a+mp+sec+neon-fp16, the
difference in the threader is that we used to thread 6->4->3 in DOM2, but we no
longer do so because doing so would rotate the loop:
a.c.127t.dom2:Path rotates loop: Cancelling jump thread: (6, 4) incoming
edge; (4, 3) normal;
I still think testing for some magic code size is fragile at best.
