From: Paul Koning <paulkoning@comcast.net>
To: Paul Koning <paulkoning@comcast.net>
Cc: Segher Boessenkool <segher@kernel.crashing.org>,
GCC Development <gcc@gcc.gnu.org>
Subject: Re: LRA produces RTL not meeting constraint
Date: Wed, 11 Jan 2023 20:17:34 -0500 [thread overview]
Message-ID: <38B62B43-951F-4415-8D4E-1E804A7CA93A@comcast.net> (raw)
In-Reply-To: <9752D10A-310F-4015-ABA2-48638E9294E3@comcast.net>
> On Jan 11, 2023, at 7:38 PM, Paul Koning via Gcc <gcc@gcc.gnu.org> wrote:
>
>
>
>> On Jan 11, 2023, at 2:52 PM, Segher Boessenkool <segher@kernel.crashing.org> wrote:
>>
>> Hi Paul,
>>
>> On Tue, Jan 10, 2023 at 02:39:34PM -0500, Paul Koning via Gcc wrote:
>>> In pdp11.md I have:
>>>
>>> (define_insn_and_split "addhi3"
>>> [(set (match_operand:HI 0 "nonimmediate_operand" "=rR,rR,Q,Q")
>>> (plus:HI (match_operand:HI 1 "general_operand" "%0,0,0,0")
>>> (match_operand:HI 2 "general_operand" "rRLM,Qi,rRLM,Qi")))]
>>> ""
>>> "#"
>>> "reload_completed"
>>> [(parallel [(set (match_dup 0)
>>> (plus:HI (match_dup 1) (match_dup 2)))
>>> (clobber (reg:CC CC_REGNUM))])]
>>> ""
>>> [(set_attr "length" "2,4,4,6")])
>>>
>>> While compiling libgcc2.c I see this RTL in the .ira dump file:
>>>
>>> (insn 49 48 53 5 (set (reg/f:HI 136)
>>> (plus:HI (reg/f:HI 5 r5)
>>> (const_int -8 [0xfffffffffffffff8]))) "../../../../../gcc/libgcc/libgcc2.c":276:4 68 {addhi3}
>>> (expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5)
>>> (const_int -8 [0xfffffffffffffff8]))
>>> (nil)))
>>
>> What hard register was assigned by IRA to r136? It shows this in the
>> .ira dump file, search for "Disposition:".
>
> Disposition:
> 3:r25 l0 mem 40:r26 l0 4 51:r31 l0 mem 47:r35 l0 mem
> 42:r45 l0 2 18:r47 l0 mem 38:r52 l0 mem 34:r54 l0 mem
> 29:r64 l0 2 21:r80 l0 0 15:r88 l0 0 2:r99 l0 0
> 19:r102 l0 mem 5:r103 l0 mem 31:r110 l0 0 44:r114 l0 0
> 41:r115 l0 mem 46:r116 l0 0 28:r117 l0 mem 33:r118 l0 0
> 20:r119 l0 2 14:r120 l0 2 1:r121 l0 2 0:r122 l0 mem
> 9:r123 l0 mem 8:r124 l0 mem 55:r125 l0 0 53:r126 l0 mem
> 54:r129 l0 0 52:r135 l0 0 49:r136 l0 5 48:r137 l0 4
> 50:r139 l0 0 45:r145 l0 mem 43:r146 l0 0 39:r147 l0 0
> 36:r148 l0 5 35:r149 l0 4 37:r151 l0 0 32:r157 l0 mem
> 30:r158 l0 0 27:r159 l0 0 25:r160 l0 mem 26:r161 l0 0
> 24:r164 l0 0 22:r165 l0 mem 23:r166 l0 0 16:r170 l0 mem
> 17:r171 l0 0 11:r175 l0 0 13:r176 l0 2 12:r177 l0 2
> 10:r178 l0 0 6:r179 l0 mem 7:r180 l0 0 4:r184 l0 0
>
> so R5, if I read that correctly. Which makes sense given that the input operand is R5.
>>
>>> Then in the .reload dump it appears this way:
>>>
>>> (insn 49 48 53 5 (set (reg/f:HI 5 r5 [136])
>>> (plus:HI (reg/f:HI 6 sp)
>>> (const_int 40 [0x28]))) "../../../../../gcc/libgcc/libgcc2.c":276:4 68 {addhi3}
>>> (expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5)
>>> (const_int -8 [0xfffffffffffffff8]))
>>> (nil)))
>>>
>>> which obviously causes an ICE because that RTL doesn't meet the constraints.
>>
>> Before reload it did not have operands[0] and operands[1] the same,
>> already?
>
> No, and given that it's an addhi3 pattern that is fine before reload. It's reload that has to make them match because the machine instruction is two operand.
It occurs to me there's a strange transformation LRA made that I don't understand, which is the cause of the trouble.
Input:
(insn 49 48 53 5 (set (reg/f:HI 136)
(plus:HI (reg/f:HI 5 r5)
(const_int -8 [0xfffffffffffffff8]))) "_mulvdi3.i":38:4 68 {addhi3}
(expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5)
(const_int -8 [0xfffffffffffffff8]))
(nil)))
(insn 53 49 50 5 (set (reg/f:HI 137)
(symbol_ref:HI ("__muldi3") [flags 0x41] <function_decl 0x104927d00 __muldi3>)) "_mulvdi3.i":38:4 25 {movhi}
(expr_list:REG_EQUIV (symbol_ref:HI ("__muldi3") [flags 0x41] <function_decl 0x104927d00 __muldi3>)
(nil)))
and the IRA "disposition" says it assigned R5 for R136, which is what should happen given that operand 1 (in the plus:HI) is R5 and the constraint says that operands 0 and 1 should match.
However, Reload shows that it is given:
(insn 49 48 53 5 (set (reg/f:HI 5 r5 [136])
(plus:HI (reg/f:HI 6 sp)
(const_int 40 [0x28]))) "_mulvdi3.i":38:4 68 {addhi3}
(expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5)
(const_int -8 [0xfffffffffffffff8]))
(nil)))
In other words, R136 was replaced by R5 as expected -- but at the same time, the source operands were replaced by something entirely different. It is a misguided attempt to eliminate the frame pointer? R5 can be the frame pointer, if it is needed for that purpose. And replacing an FP reference by an SP reference is reasonable enough, but such a substitution has to verify that the constraints are still satisfied. Is that something the target code has to provide? I'm not aware of it.
paul
next prev parent reply other threads:[~2023-01-12 1:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-10 19:39 Paul Koning
2023-01-11 19:52 ` Segher Boessenkool
2023-01-12 0:38 ` Paul Koning
2023-01-12 1:17 ` Paul Koning [this message]
2023-01-12 16:23 ` Segher Boessenkool
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=38B62B43-951F-4415-8D4E-1E804A7CA93A@comcast.net \
--to=paulkoning@comcast.net \
--cc=gcc@gcc.gnu.org \
--cc=segher@kernel.crashing.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).