Hello,
I'm writing a simple gcc backend and I'm experiencing a weird thing
regarding address legitimation process. Two scenarios:
If I only allow addresses to be either a register or symbols my gcc
works. To do so I add the restrictions into the
TARGET_LEGITIMATE_ADDRESS_P macro. This makes gcc t
On Fri, 14 Mar 2014 12:52:35 +0100
David Guillen wrote:
> If I allow also a 'PLUS' expression to be a valid address (adding the
> restriction that the two addends are a register and a constant) it
> happens (sometimes) that gcc comes up with an expression like this
> one:
>
> (plus:SI (plus
Thanks for you info Julian.
I actually read all the docs and I think I 'more or less' understand
the inner workings of gcc.
What surprises me most is that during the non-strict RTL generation I
do not see any 'strange' address pattern but during the post-reload
process the non-legitimate address c
On 03/14/14 05:52, David Guillen wrote:
Hello,
I'm writing a simple gcc backend and I'm experiencing a weird thing
regarding address legitimation process. Two scenarios:
If I only allow addresses to be either a register or symbols my gcc
works. To do so I add the restrictions into the
TARGET_LE
David Guillen writes:
> In any case I'm not using the restrict variable and I'm assuming
> strict is zero, this is, not checking the hard regsiters themselves.
> This is because any reg is OK for base reg. I'm pretty sure I'm
> behaving similarly to arm, cris or x86 backends.
"strict" doesn't me
Thanks for the information.
So far I'm still facing problems regarding memory addresses even with
the most restrictive conditions. The non-recognized instruction is:
../../../libgcc/libgcc2.c: In function '__muldi3':
../../../libgcc/libgcc2.c:559:1: error: insn not satisfying its restrictions:
(
David Guillen writes:
> So far I'm still facing problems regarding memory addresses even with
> the most restrictive conditions. The non-recognized instruction is:
>
> ../../../libgcc/libgcc2.c: In function '__muldi3':
> ../../../libgcc/libgcc2.c:559:1: error: insn not satisfying its restrictions
Richard Sandiford writes:
> What DJ meant below was that you should reject all pseudo registers
> if strict_p. I.e. REG_P (foo) should be:
>
>REG_P (foo) && (!strict_p || REGNO_MODE_OK_FOR_BASE_P (foo, mode))
sorry:
REG_P (foo) && (!strict_p || REGNO_MODE_OK_FOR_BASE_P (REGNO (foo), mode)
Yep thanks,
As you guys pointed the problem was the improper handling of the
strict_p parameter.
Thanks!
2014-03-18 20:13 GMT+01:00 Richard Sandiford :
> Richard Sandiford writes:
>> What DJ meant below was that you should reject all pseudo registers
>> if strict_p. I.e. REG_P (foo) should be:
