public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* Issue with GCC reload
@ 2020-11-04 10:05 Henri Cloetens
  2020-11-04 17:21 ` Henri Cloetens
  0 siblings, 1 reply; 2+ messages in thread
From: Henri Cloetens @ 2020-11-04 10:05 UTC (permalink / raw)
  To: gcc-help; +Cc: Segher Boessenkool

Hello all,

Continuing with my custom backend, I get another error. (during reload)

/home/henri/blueICe/gcc/newlib/newlib/libc/stdlib/ldtoa.c:1128:1: error: 
unable to generate reloads for:
  1128 | }
       | ^
 > (insn 247 246 298 14 (set (mem/c:SI (plus:SI (reg/f:SI 67 sfp)
 >                 (const_int 32 [0x20])) [40 %sfp+32 S4 A32])
 >        (zero_extend:SI (mem:HI (plus:SI (reg/v/f:SI 231 [ ldp ])
 >                   (const_int 76 [0x4c])) [1 MEM[(short unsigned int 
*)ldp_25(D) + 76B]+0 S2 A32])))
"/home/henri/blueICe/gcc/newlib/newlib/libc/stdlib/ldtoa.c":1124:14 43 
{zero_extendhisi2_internal}
      (expr_list:REG_DEAD (reg/v/f:SI 231 [ ldp ])

What happened is,
a. In the first pass, it put this in a register. Something like

   > (insn 247 246 298 14 (set (reg: SI 999)
 >        (zero_extend:SI (mem:HI (plus:SI (reg/v/f:SI 231 [ ldp ])
 >                   (const_int 76 [0x4c])) [1 MEM[(short unsigned int 
*)ldp_25(D) + 76B]+0 S2 A32])))

b. Then, during reload, it needs to move this to the stack. What I then 
found in the documentation,
     is the reload code calls my hook "blueproc_secondary_reload", and 
the hook then returns the
     instruction to do the reload with, and the register class of the 
register to use for the reload.
     Now, this is what my code logged for this call :

 > reload using movhi

 > blueproc_secondary_reload , return BASE_REGS, rclass = GENERAL_REGS, 
mode = HI, type 0 calls : 3667 x:
 > (mem:HI (plus:SI (reg/v/f:SI 231 [ ldp ])
 >         (const_int 76 [0x4c])) [1 MEM[(short unsigned int *)ldp_25(D) 
+ 76B]+0 S2 A32])

And .. there it goes wrong !. The hook returns the reload instruction 
"movhi", but here, because of the zero extend,
the other instruction is needed !. (zero_extendhisi2) The reason for 
this mistake is not in my code. The issue is, it
gets called with an incorrect RTX:

(mem:HI (plus:SI (reg/v/f:SI 231 [ ldp ])

This is not the operation the reload needs to do. On top of the memory 
load, the zero_extend is needed, but the
reload hook does not receive this. As a result, it returns the wrong 
instruction, and the compiler crashes.

Best Regards,

Henri.



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Issue with GCC reload
  2020-11-04 10:05 Issue with GCC reload Henri Cloetens
@ 2020-11-04 17:21 ` Henri Cloetens
  0 siblings, 0 replies; 2+ messages in thread
From: Henri Cloetens @ 2020-11-04 17:21 UTC (permalink / raw)
  To: gcc-help

Hello all,

I have been looking myself; I find the behavior of the routine 
*/check_and_process_move
/*in lra-constraints.c strange.

- This routine seems to do the reload.
- It does this as follows: (simplified)
   1. It does some checking
   2. it calls some hooks
   3. It calls the hook *targetm.secondary_reload
*    3a If the hook returns "CODE_FOR_nothing", it does a default action:
        It implements a move from source to destination.
     3b If the hook returns anything else, it does the action specified 
by the hook
   -> Now, the problem is, that the checking done in 1. is only valid 
for the case 3a:
        the hook returning. CODE_FOR_nothing. It namely checks :
   > if (! (REG_P (dreg) || MEM_P (dreg)) || ! (REG_P (sreg) || MEM_P 
(sreg)))
   >  return false;
-> In this line, it fails if the source is not a REG_P or a MEM_P.
In my case, the source is a zero_extend(MEM_P), and this is not a MEM_P.
The problem of this, however, is that this decision to fail is 
premature. I mean, this is a
valid decision if the hook targetm.secondary_reload return 
CODE_FOR_nothing. I dont see why
it is not allowed to implement this kind of reload in the hook. Ie. a 
reload for a memory operation of the
type zero_extend(MEM_P) or sign_extend(MEM_P).

Best Regards,

Henri.


/static bool//
//check_and_process_move (bool *change_p, bool *sec_mem_p ATTRIBUTE_UNUSED)/
starting in lra-constraints.c, line

On 11/4/20 11:05 AM, Henri Cloetens wrote:
> Hello all,
>
> Continuing with my custom backend, I get another error. (during reload)
>
> /home/henri/blueICe/gcc/newlib/newlib/libc/stdlib/ldtoa.c:1128:1: 
> error: unable to generate reloads for:
>  1128 | }
>       | ^
> > (insn 247 246 298 14 (set (mem/c:SI (plus:SI (reg/f:SI 67 sfp)
> >                 (const_int 32 [0x20])) [40 %sfp+32 S4 A32])
> >        (zero_extend:SI (mem:HI (plus:SI (reg/v/f:SI 231 [ ldp ])
> >                   (const_int 76 [0x4c])) [1 MEM[(short unsigned int 
> *)ldp_25(D) + 76B]+0 S2 A32])))
> "/home/henri/blueICe/gcc/newlib/newlib/libc/stdlib/ldtoa.c":1124:14 43 
> {zero_extendhisi2_internal}
>      (expr_list:REG_DEAD (reg/v/f:SI 231 [ ldp ])
>
> What happened is,
> a. In the first pass, it put this in a register. Something like
>
>   > (insn 247 246 298 14 (set (reg: SI 999)
> >        (zero_extend:SI (mem:HI (plus:SI (reg/v/f:SI 231 [ ldp ])
> >                   (const_int 76 [0x4c])) [1 MEM[(short unsigned int 
> *)ldp_25(D) + 76B]+0 S2 A32])))
>
> b. Then, during reload, it needs to move this to the stack. What I 
> then found in the documentation,
>     is the reload code calls my hook "blueproc_secondary_reload", and 
> the hook then returns the
>     instruction to do the reload with, and the register class of the 
> register to use for the reload.
>     Now, this is what my code logged for this call :
>
> > reload using movhi
>
> > blueproc_secondary_reload , return BASE_REGS, rclass = GENERAL_REGS, 
> mode = HI, type 0 calls : 3667 x:
> > (mem:HI (plus:SI (reg/v/f:SI 231 [ ldp ])
> >         (const_int 76 [0x4c])) [1 MEM[(short unsigned int 
> *)ldp_25(D) + 76B]+0 S2 A32])
>
> And .. there it goes wrong !. The hook returns the reload instruction 
> "movhi", but here, because of the zero extend,
> the other instruction is needed !. (zero_extendhisi2) The reason for 
> this mistake is not in my code. The issue is, it
> gets called with an incorrect RTX:
>
> (mem:HI (plus:SI (reg/v/f:SI 231 [ ldp ])
>
> This is not the operation the reload needs to do. On top of the memory 
> load, the zero_extend is needed, but the
> reload hook does not receive this. As a result, it returns the wrong 
> instruction, and the compiler crashes.
>
> Best Regards,
>
> Henri.
>
>


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-11-04 17:20 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-04 10:05 Issue with GCC reload Henri Cloetens
2020-11-04 17:21 ` Henri Cloetens

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).