[RFA,Bug,target/108892,13,regression] Force re-recognition after changing RTL structure of an insn

  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.



>                   /* Temporarily replace the set's source with the
>                      contents of the REG_EQUAL note.  The insn will
>                      be deleted or recognized by try_combine.  */
>                   rtx orig_src = SET_SRC (set); 
>                   rtx orig_dest = SET_DEST (set); 
>                   if (GET_CODE (SET_DEST (set)) == ZERO_EXTRACT)
>                     SET_DEST (set) = XEXP (SET_DEST (set), 0);
>                   SET_SRC (set) = note;
>                   i2mod = temp;
>                   i2mod_old_rhs = copy_rtx (orig_src);
>                   i2mod_new_rhs = copy_rtx (note);
>                   next = try_combine (insn, i2mod, NULL, NULL,
>                                       &new_direct_jump_p, 
>                                       last_combined_insn);
>                   i2mod = NULL;
>                   if (next)
>                     {
>                       statistics_counter_event (cfun, "insn-with-note combine", 1);
>                       goto retry;
>                     } 
>                   SET_SRC (set) = orig_src;
>                   SET_DEST (set) = orig_dest;


This code replaces the SET_SRC of an insn in the RTL stream with the 
contents of a REG_EQUAL note.  So given an insn like this:

> (insn 122 117 127 2 (set (reg:DI 157 [ _46 ])
>         (ior:DI (reg:DI 200)
>             (reg:DI 251))) "j.c":14:5 -1
>      (expr_list:REG_EQUAL (const_int 25769803782 [0x600000006])
>         (nil)))

It replaces the (ior ...) with a (const_int ...).  The resulting insn is 
passed to try_combine which will try to recognize it, then use it in a 
combination attempt.  Recognition succeeds with the special 
define_insn_and_split pattern in the risc-v backend resulting in:

> (insn 122 117 127 2 (set (reg:DI 157 [ _46 ])
>         (const_int 25769803782 [0x600000006])) "j.c":14:5 177 {*mvconst_internal}
>      (expr_list:REG_EQUAL (const_int 25769803782 [0x600000006])
>         (nil)))

This is as-expected.  Now assume we were unable to combine anything, so 
try_combine returns NULL_RTX.  The quoted code above restores SET_SRC 
(and SET_DEST) resulting in:

> (insn 122 117 127 2 (set (reg:DI 157 [ _46 ])
>         (ior:DI (reg:DI 200)
>             (reg:DI 251))) "j.c":14:5 177 {*mvconst_internal}
>      (expr_list:REG_EQUAL (const_int 25769803782 [0x600000006])
>         (nil)))


But this doesn't get re-recognized and we ICE later in LRA.

The fix is trivial, reset the INSN_CODE to force re-recognition in the 
case where try_combine fails.

Bootstrapped and regression tested on x86_64 and riscv.   OK for the trunk?

Jeff
gcc/
	* combine.cc (combine_instructions): Force re-recognition when
	potentially changing the underlying RTL structure of an insn.

gcc/testsuite/
	* gcc.c-torture/compile/pr108892.c: New test
  

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