| Message ID | b5d34537-c54b-ebac-7c7d-89380cf9fe46@ventanamicro.com |
|---|---|
| State | New |
| Headers | show |
| Series | [RFA,Bug,target/108892,13,regression] Force re-recognition after changing RTL structure of an insn | expand |
Hi! On Wed, Mar 29, 2023 at 07:48:00AM -0600, Jeff Law wrote: > So as mentioned in the PR the underlying issue here is combine changes > the form of an existing insn, but fails to force re-recognition. As a > result other parts of the compiler blow up. [snip] > The fix is trivial, reset the INSN_CODE to force re-recognition in the > case where try_combine fails. Thanks for the clear explanation! Okay for trunk. Also okay for all backports (after a week or so on trunk). > * combine.cc (combine_instructions): Force re-recognition when > potentially changing the underlying RTL structure of an insn. When returning the original, might be clearer? Thanks, Segher
On 4/5/23 08:21, Segher Boessenkool wrote: > Hi! > > On Wed, Mar 29, 2023 at 07:48:00AM -0600, Jeff Law wrote: >> So as mentioned in the PR the underlying issue here is combine changes >> the form of an existing insn, but fails to force re-recognition. As a >> result other parts of the compiler blow up. > > [snip] > >> The fix is trivial, reset the INSN_CODE to force re-recognition in the >> case where try_combine fails. > > Thanks for the clear explanation! Okay for trunk. Also okay for all > backports (after a week or so on trunk). Thanks. I haven't seen this on any of the release branches, so no strong opinions on backporting at this time. It's a pretty narrow bug (no surprise given its been latent for something like 10 years). > >> * combine.cc (combine_instructions): Force re-recognition when >> potentially changing the underlying RTL structure of an insn. > > When returning the original, might be clearer? Yea. I'll update the ChangeLog entry. Thanks, Jeff
On Wed, Apr 05, 2023 at 09:07:30AM -0600, Jeff Law wrote: > On 4/5/23 08:21, Segher Boessenkool wrote: > >On Wed, Mar 29, 2023 at 07:48:00AM -0600, Jeff Law wrote: > >>So as mentioned in the PR the underlying issue here is combine changes > >>the form of an existing insn, but fails to force re-recognition. As a > >>result other parts of the compiler blow up. > > > >[snip] > > > >>The fix is trivial, reset the INSN_CODE to force re-recognition in the > >>case where try_combine fails. > > > >Thanks for the clear explanation! Okay for trunk. Also okay for all > >backports (after a week or so on trunk). > Thanks. I haven't seen this on any of the release branches, so no > strong opinions on backporting at this time. It's a pretty narrow bug > (no surprise given its been latent for something like 10 years). Right. But it seems to me it has been there all those years? Does the new testcase fail on older branches? Even if not, it seems clear it is wrong on the older branches as well! But if you think it is too dangerous to backport, let's not. Thanks, Segher
On 4/5/23 11:38, Segher Boessenkool wrote: > On Wed, Apr 05, 2023 at 09:07:30AM -0600, Jeff Law wrote: >> On 4/5/23 08:21, Segher Boessenkool wrote: >>> On Wed, Mar 29, 2023 at 07:48:00AM -0600, Jeff Law wrote: >>>> So as mentioned in the PR the underlying issue here is combine changes >>>> the form of an existing insn, but fails to force re-recognition. As a >>>> result other parts of the compiler blow up. >>> >>> [snip] >>> >>>> The fix is trivial, reset the INSN_CODE to force re-recognition in the >>>> case where try_combine fails. >>> >>> Thanks for the clear explanation! Okay for trunk. Also okay for all >>> backports (after a week or so on trunk). >> Thanks. I haven't seen this on any of the release branches, so no >> strong opinions on backporting at this time. It's a pretty narrow bug >> (no surprise given its been latent for something like 10 years). > > Right. But it seems to me it has been there all those years? Does the > new testcase fail on older branches? Even if not, it seems clear it is > wrong on the older branches as well! I bet if I put the special pattern into an old branch, then ran the testcase it'd probably trigger. > > But if you think it is too dangerous to backport, let's not. It should be crazy safe. Not a tall worried about it being dangerous. More a case of not seeing a lot of value given how narrow the problem is. jeff
Hi again, On Wed, Apr 05, 2023 at 11:43:30AM -0600, Jeff Law wrote: > On 4/5/23 11:38, Segher Boessenkool wrote: > >Right. But it seems to me it has been there all those years? Does the > >new testcase fail on older branches? Even if not, it seems clear it is > >wrong on the older branches as well! > I bet if I put the special pattern into an old branch, then ran the > testcase it'd probably trigger. > > >But if you think it is too dangerous to backport, let's not. > It should be crazy safe. Not a tall worried about it being dangerous. > More a case of not seeing a lot of value given how narrow the problem is. Please just do the usual then? git cherry-pick -x $some_hash on the release branches, and push it if that works flawlessly? And if it doesn't, *that* is a good reason to skip backporting it, sure :-) Segher
On 4/5/23 13:02, Segher Boessenkool wrote: > Hi again, > > On Wed, Apr 05, 2023 at 11:43:30AM -0600, Jeff Law wrote: >> On 4/5/23 11:38, Segher Boessenkool wrote: >>> Right. But it seems to me it has been there all those years? Does the >>> new testcase fail on older branches? Even if not, it seems clear it is >>> wrong on the older branches as well! >> I bet if I put the special pattern into an old branch, then ran the >> testcase it'd probably trigger. >> >>> But if you think it is too dangerous to backport, let's not. >> It should be crazy safe. Not a tall worried about it being dangerous. >> More a case of not seeing a lot of value given how narrow the problem is. > > Please just do the usual then? git cherry-pick -x $some_hash on the > release branches, and push it if that works flawlessly? And if it > doesn't, *that* is a good reason to skip backporting it, sure :-) Well, the usual for something like this is to wait, at least for me. Jeff
diff --git a/gcc/combine.cc b/gcc/combine.cc index 053879500b7..22bf8e1ec89 100644 --- a/gcc/combine.cc +++ b/gcc/combine.cc @@ -1416,6 +1416,7 @@ combine_instructions (rtx_insn *f, unsigned int nregs) statistics_counter_event (cfun, "insn-with-note combine", 1); goto retry; } + INSN_CODE (temp) = -1; SET_SRC (set) = orig_src; SET_DEST (set) = orig_dest; } diff --git a/gcc/testsuite/gcc.c-torture/compile/pr108892.c b/gcc/testsuite/gcc.c-torture/compile/pr108892.c new file mode 100644 index 00000000000..d7fecd54ecf --- /dev/null +++ b/gcc/testsuite/gcc.c-torture/compile/pr108892.c @@ -0,0 +1,23 @@ +typedef char __attribute__((__vector_size__ (64))) U; +typedef int __attribute__((__vector_size__ (64))) V; + +int g; +U u; + +static inline __attribute__((__always_inline__)) void +bar (short a, short b, V w) +{ + V v = __builtin_shufflevector ((V) { }, a % (0 != w), 17, 22, 20, 15, + 20, 23, 17, 20, 16, 21, 16, 19, 18, 14, 15, + 14) ^ b; + g *= __builtin_memcmp_eq (0, 0, 2); + v |= 6; + __builtin_ilogb (0); + u = (U) w + (U) v; +} + +void +foo (void) +{ + bar (5, 4, (V){30, 4, 1, 5, 6}); +}