diff mbox

Avoid PR72749 by not using unspecs

Message ID CAFULd4Y2cxgZE8XV=Wxz=-jLzdaNO6hoz+A0rXKb9XPQr6ju_Q@mail.gmail.com
State New
Headers show

Commit Message

Uros Bizjak Jan. 14, 2017, 10:19 a.m. UTC 
On Fri, Jan 13, 2017 at 4:58 PM, Uros Bizjak <ubizjak@gmail.com> wrote:
> On Fri, Jan 13, 2017 at 12:50 PM, Alan Modra <amodra@gmail.com> wrote:
>> Rather than using unspecs in doloop insns to stop combine creating
>> these insns, use legitimate_combined_insn.
>>
>> I'm not sure why the original patch implementing
>> legitimate_combined_insn did not store the result of recog to the insn
>> but it seems good to me, and would allow the recog call in
>> ix86_legitimate_combined_insn to be omitted.  (I tested that too, not
>> shown here.)
>
> IIRC, I copied operand scanning loop from recog.c (around line 2580)
> and the function was later enhanced with preferred alternatives
> handling. The function worked well, and not being an expert in this
> area, I didn't try to "optimize" the code that worked...
>
> So, there is no particular reason for the current implementation.

FYI, the following patch immediately crashed build:

--cut here--
--cut here--

/home/uros/gcc-svn/trunk/libgcc/libgcc2.c:557:1: internal compiler
error: Segmentation fault
 }
 ^
0xe82bcc crash_signal
        /home/uros/gcc-svn/trunk/gcc/toplev.c:333
0x1621444 insn_extract(rtx_insn*)
        /ssd/uros/gcc-build/gcc/insn-extract.c:7453
0xd9e345 extract_insn(rtx_insn*)
        /home/uros/gcc-svn/trunk/gcc/recog.c:2317
0x126e662 ix86_legitimate_combined_insn
        /home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:8137
0x1814568 recog_for_combine_1
        /home/uros/gcc-svn/trunk/gcc/combine.c:11206
0x1814d73 recog_for_combine
        /home/uros/gcc-svn/trunk/gcc/combine.c:11363
0x17ffb69 try_combine
        /home/uros/gcc-svn/trunk/gcc/combine.c:3824
0x17f8d7e combine_instructions
        /home/uros/gcc-svn/trunk/gcc/combine.c:1372
0x181cb67 rest_of_handle_combine
        /home/uros/gcc-svn/trunk/gcc/combine.c:14607
0x181cc28 execute
        /home/uros/gcc-svn/trunk/gcc/combine.c:14652

It looks that recog_for_combine doesn't do everything recog does.

Uros.

Comments

Uros Bizjak Jan. 14, 2017, 10:26 a.m. UTC | #1 
On Sat, Jan 14, 2017 at 11:19 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
> On Fri, Jan 13, 2017 at 4:58 PM, Uros Bizjak <ubizjak@gmail.com> wrote:
>> On Fri, Jan 13, 2017 at 12:50 PM, Alan Modra <amodra@gmail.com> wrote:
>>> Rather than using unspecs in doloop insns to stop combine creating
>>> these insns, use legitimate_combined_insn.
>>>
>>> I'm not sure why the original patch implementing
>>> legitimate_combined_insn did not store the result of recog to the insn
>>> but it seems good to me, and would allow the recog call in
>>> ix86_legitimate_combined_insn to be omitted.  (I tested that too, not
>>> shown here.)
>>
>> IIRC, I copied operand scanning loop from recog.c (around line 2580)
>> and the function was later enhanced with preferred alternatives
>> handling. The function worked well, and not being an expert in this
>> area, I didn't try to "optimize" the code that worked...
>>
>> So, there is no particular reason for the current implementation.
>
> FYI, the following patch immediately crashed build:

Bah, it would help if I actually saved source with proposed combine.c change.

Testing the patch...

Uros.
diff mbox

Patch

Index: i386.c
===================================================================
--- i386.c      (revision 244463)
+++ i386.c      (working copy)
@@ -8130,7 +8130,7 @@  ix86_legitimate_combined_insn (rtx_insn *insn)
      generating insn patterns with invalid hard register operands.
      These invalid insns can eventually confuse reload to error out
      with a spill failure.  See also PRs 46829 and 46843.  */
-  if ((INSN_CODE (insn) = recog (PATTERN (insn), insn, 0)) >= 0)
+  if (INSN_CODE (insn) >= 0)
     {
       int i;