On 2/10/25 2:22 AM, Georg-Johann Lay wrote:
Then avr.cc has this:
/* Implement `TARGET_LEGITIMATE_COMBINED_INSN'. */
/* PR78883: Filter out paradoxical SUBREGs of MEM which are not handled
properly by following passes. As INSN_SCHEDULING is off and hence
general_operand accepts suc
Am 09.02.25 um 17:30 schrieb Jeff Law:
On 2/9/25 1:10 AM, Georg-Johann Lay wrote:
The .ira dump has several paradoxical subregs like:
(insn 22 21 60 4 (set (reg/v:SI 51 [ val32 ])
(subreg:SI (reg:HI 53 [ t$val ]) 0)) "pr116389-red.c":14:14
146 {*movsi_split}
(insn 27 26 28 5 (set (r
On 2/9/25 1:10 AM, Georg-Johann Lay wrote:
The .ira dump has several paradoxical subregs like:
(insn 22 21 60 4 (set (reg/v:SI 51 [ val32 ])
(subreg:SI (reg:HI 53 [ t$val ]) 0)) "pr116389-red.c":14:14
146 {*movsi_split}
(insn 27 26 28 5 (set (reg/v:SI 51 [ val32 ])
(subreg
CCing Denis
Am 08.02.25 um 23:51 schrieb Jeff Law:
On 2/8/25 1:52 PM, Georg-Johann Lay wrote:
Am 08.02.25 um 18:23 schrieb Jeff Law:
On 2/8/25 3:04 AM, Georg-Johann Lay wrote:
That test case from https://gcc.gnu.org/bugzilla/show_bug.cgi?
id=116389#c7
still ICEs with that change in http://gc
On 2/8/25 1:52 PM, Georg-Johann Lay wrote:
Am 08.02.25 um 18:23 schrieb Jeff Law:
On 2/8/25 3:04 AM, Georg-Johann Lay wrote:
That test case from https://gcc.gnu.org/bugzilla/show_bug.cgi?
id=116389#c7
still ICEs with that change in http://gcc.gnu.org/r15-7428
pr116389-red.c: In func
Am 08.02.25 um 18:23 schrieb Jeff Law:
On 2/8/25 3:04 AM, Georg-Johann Lay wrote:
That test case from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116389#c7
still ICEs with that change in http://gcc.gnu.org/r15-7428
pr116389-red.c: In function 'func':
pr116389-red.c:20:1: error: insn do
On 2/8/25 3:04 AM, Georg-Johann Lay wrote:
That test case from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116389#c7
still ICEs with that change in http://gcc.gnu.org/r15-7428
pr116389-red.c: In function 'func':
pr116389-red.c:20:1: error: insn does not satisfy its constraints:
20 | }
Am 07.02.25 um 22:28 schrieb Jeff Law:
On 2/7/25 11:01 AM, Georg-Johann Lay wrote:
Am 07.02.25 um 17:12 schrieb Jeff Law:
On 2/3/25 2:09 AM, Richard Sandiford wrote:
Jeff Law writes:
So pulling on this thread leads me into the code that sets up
ALLOCNO_WMODE in create_insn_allocnos:
On 2/7/25 11:01 AM, Georg-Johann Lay wrote:
Am 07.02.25 um 17:12 schrieb Jeff Law:
On 2/3/25 2:09 AM, Richard Sandiford wrote:
Jeff Law writes:
So pulling on this thread leads me into the code that sets up
ALLOCNO_WMODE in create_insn_allocnos:
if ((a = ira_curr_regno_allocno_
Am 07.02.25 um 17:12 schrieb Jeff Law:
On 2/3/25 2:09 AM, Richard Sandiford wrote:
Jeff Law writes:
So pulling on this thread leads me into the code that sets up
ALLOCNO_WMODE in create_insn_allocnos:
if ((a = ira_curr_regno_allocno_map[regno]) == NULL)
{
On 2/3/25 2:09 AM, Richard Sandiford wrote:
Jeff Law writes:
So pulling on this thread leads me into the code that sets up
ALLOCNO_WMODE in create_insn_allocnos:
if ((a = ira_curr_regno_allocno_map[regno]) == NULL)
{
a = ira_create_allocno (regno, fals
On 2/3/25 2:09 AM, Richard Sandiford wrote:
So yeah, I think the first question is why ira_build_conflicts isn't
kicking in for this register or (if it is) why we still get register 0.
So pulling on this thread leads me into the code that sets up
ALLOCNO_WMODE in create_insn_allocnos:
Jeff Law writes:
>>> Focusing on this insn:
>>>
(insn 77 75 80 6 (parallel [
(set (reg:DI 75 [ _32 ])
(plus:DI (reg:DI 73 [ _31 ])
(subreg:DI (reg/v:SI 41 [ __n ]) 0)))
(clobber (scratch:SI))
])
[ Returning to an old discussion... ]
On 8/19/24 3:50 AM, Richard Sandiford wrote:
Jeff Law writes:
On 8/12/24 3:50 PM, Jeff Law wrote:
On 8/12/24 1:49 PM, Richard Sandiford wrote:
- regno = subreg_regno (x);
+ /* A paradoxical should always be REGNO (y) + 0. Using
subreg_re
Jeff Law writes:
> On 8/12/24 3:50 PM, Jeff Law wrote:
>>
>>
>> On 8/12/24 1:49 PM, Richard Sandiford wrote:
>>
- regno = subreg_regno (x);
+ /* A paradoxical should always be REGNO (y) + 0. Using
subreg_regno
+ for something like (subreg:DI (reg:SI N) 0)
On 8/18/24 10:40 AM, Jeff Law wrote:
After the discussion from last week, I'm leaning a bit more towards no
than before.
Let's take a simpler case, the meaning of:
(subreg:DI (reg:SI 1) 0)
Actually refers to d0, not d1 on the m68k. If we agree on that, then
(subreg:DI (reg:SI 0) 0)
Lo
On 8/12/24 3:50 PM, Jeff Law wrote:
On 8/12/24 1:49 PM, Richard Sandiford wrote:
- regno = subreg_regno (x);
+ /* A paradoxical should always be REGNO (y) + 0. Using
subreg_regno
+ for something like (subreg:DI (reg:SI N) 0) on a
WORDS_BIG_ENDIAN
+ target will
On 8/13/24 3:19 AM, Richard Sandiford wrote:
And the inconsistency was driving me bananas as my mental model is that
(reg:DI N) covers N and N+1 and all that changes in the order based on
endianness. ie, if we have (set (reg:DI 0) (...)) that changes d0/d1.
But maybe that's just 20 year
Jeff Law writes:
> On 8/12/24 4:02 PM, Richard Sandiford wrote:
>> Jeff Law writes:
>>> On 8/12/24 1:49 PM, Richard Sandiford wrote:
>>>
>
> - regno = subreg_regno (x);
> + /* A paradoxical should always be REGNO (y) + 0. Using subreg_regno
> + for something like (su
On 8/12/24 4:02 PM, Richard Sandiford wrote:
Jeff Law writes:
On 8/12/24 1:49 PM, Richard Sandiford wrote:
- regno = subreg_regno (x);
+ /* A paradoxical should always be REGNO (y) + 0. Using subreg_regno
+for something like (subreg:DI (reg:SI N) 0) on a WORDS_BI
Jeff Law writes:
> On 8/12/24 1:49 PM, Richard Sandiford wrote:
>
>>>
>>> - regno = subreg_regno (x);
>>> + /* A paradoxical should always be REGNO (y) + 0. Using subreg_regno
>>> +for something like (subreg:DI (reg:SI N) 0) on a WORDS_BIG_ENDIAN
>>> +target will return
On 8/12/24 1:49 PM, Richard Sandiford wrote:
- regno = subreg_regno (x);
+ /* A paradoxical should always be REGNO (y) + 0. Using subreg_regno
+for something like (subreg:DI (reg:SI N) 0) on a WORDS_BIG_ENDIAN
+target will return N-1 which is catastrophic
Jeff Law writes:
> So this is another nasty latent bug exposed by ext-dce.
>
> Similar to the prior m68k failure it's another problem with how we
> handle paradoxical subregs on big endian targets.
>
> In this instance when we remove the hard subregs we take something like:
>
> (subreg:DI (reg:SI
So this is another nasty latent bug exposed by ext-dce.
Similar to the prior m68k failure it's another problem with how we
handle paradoxical subregs on big endian targets.
In this instance when we remove the hard subregs we take something like:
(subreg:DI (reg:SI 0) 0)
And turn it into
(r
24 matches
Mail list logo
