Address rejected by TARGET_LEGITIMATE_ADDRESS_P recreated in post reload CSE pass at -O2

Address rejected by TARGET_LEGITIMATE_ADDRESS_P recreated in post reload CSE pass at -O2

[Ayonam Ray]

Hi,

I have an address (symbolicRef + indexReg * scaleFactor) that is
rejected by my TARGET_LEGITIMATE_ADDRESS_P.  However, at -O2, the same
address gets recreated in the post reload CSE pass.  The symbolic
reference just after the reload is in a register and the address
"register + indexReg * scaleFactor" is a valid address for my
architecture.  The CSE figures out that the symbolic reference is in a
register (the notes say so) and replaces the "register + indexReg *
scaleFactor" address with "symbolicRef + indexReg * scaleFactor".

Is there a way to prevent this from happening?  Am I missing some
target definitions which is causing this?  Or is it an incorrect
predicate definition?

I get the failure in "movsi" when, after the post reload CSE, it tries
to match the constraints for that memory operand.  The 'm' constraint
ends up calling the TARGET_LEGITIMATE_ADDRESS_P which returns a zero
and the constraint check fails.

Thanks in advance.
Regards
Ayonam

Re: Address rejected by TARGET_LEGITIMATE_ADDRESS_P recreated in post reload CSE pass at -O2

[Ian Lance Taylor]

Ayonam Ray <ayonam@gmail.com> writes:

> I have an address (symbolicRef + indexReg * scaleFactor) that is
> rejected by my TARGET_LEGITIMATE_ADDRESS_P.  However, at -O2, the same
> address gets recreated in the post reload CSE pass.  The symbolic
> reference just after the reload is in a register and the address
> "register + indexReg * scaleFactor" is a valid address for my
> architecture.  The CSE figures out that the symbolic reference is in a
> register (the notes say so) and replaces the "register + indexReg *
> scaleFactor" address with "symbolicRef + indexReg * scaleFactor".
>
> Is there a way to prevent this from happening?  Am I missing some
> target definitions which is causing this?  Or is it an incorrect
> predicate definition?
>
> I get the failure in "movsi" when, after the post reload CSE, it tries
> to match the constraints for that memory operand.  The 'm' constraint
> ends up calling the TARGET_LEGITIMATE_ADDRESS_P which returns a zero
> and the constraint check fails.

I'm really guessing here, but it sounds like you have an insn with an
operand that uses an m constraint but for which the operand predicate
accepts operands that do not meet that constraint.  In general for every
RTL that the operand predicate accepts you must have a constraint that
can match that operand.  Based on your description even general_operand
ought to reject the symbolicRef address.

Ian

Re: Address rejected by TARGET_LEGITIMATE_ADDRESS_P recreated in post reload CSE pass at -O2

[Ayonam Ray]

On 22 May 2012 19:18, Ian Lance Taylor <iant@google.com> wrote:
>
> I'm really guessing here, but it sounds like you have an insn with an
> operand that uses an m constraint but for which the operand predicate
> accepts operands that do not meet that constraint.  In general for every
> RTL that the operand predicate accepts you must have a constraint that
> can match that operand.  Based on your description even general_operand
> ought to reject the symbolicRef address.
>
> Ian

Thanks Ian,

It is exactly as you said.  I fixed my predicate for that instruction.
 So what was earlier a general_operand now checks for general_operand
and in addition, it checks for the operand to be a MEM (PLUS (MULT
(REG  CONST_INT))  SYMBOL_REF) and rejects those operands.

However, I still get the same problem.  What I noticed is that the
address conversion from using a REG instead of a SYMBOL_REF happens at
the IRA stage.  I presume it is having register pressure and since the
register that contains the SYMBOL_REF is used only for these kind of
addresses, it knocks off the REG and replaces it with the SYMBOL_REF
itself.  But the problem is how to make it not do so.  Does it check
the instruction predicates when it does this transformation in the
IRA?  I feel it doesn't.  It just looks at the REG_EQUIV and REG_EQUAL
expression lists and carries out the transformation based on that.

Regards
Ayonam

Re: Address rejected by TARGET_LEGITIMATE_ADDRESS_P recreated in post reload CSE pass at -O2

[Ian Lance Taylor]

Ayonam Ray <ayonam@gmail.com> writes:

> On 22 May 2012 19:18, Ian Lance Taylor <iant@google.com> wrote:
>>
>> I'm really guessing here, but it sounds like you have an insn with an
>> operand that uses an m constraint but for which the operand predicate
>> accepts operands that do not meet that constraint.  In general for every
>> RTL that the operand predicate accepts you must have a constraint that
>> can match that operand.  Based on your description even general_operand
>> ought to reject the symbolicRef address.
>>
>> Ian
>
> Thanks Ian,
>
> It is exactly as you said.  I fixed my predicate for that instruction.
>  So what was earlier a general_operand now checks for general_operand
> and in addition, it checks for the operand to be a MEM (PLUS (MULT
> (REG  CONST_INT))  SYMBOL_REF) and rejects those operands.

I'm not sure I understand this, because it sounds like that MEM is
already invalid and therefore not a general_operand.  When
general_operand sees a MEM, it checks that the address satisfies the
legitimate_address_p target hook, and I thought you indicated that such
an address would fail that hook.


> However, I still get the same problem.  What I noticed is that the
> address conversion from using a REG instead of a SYMBOL_REF happens at
> the IRA stage.  I presume it is having register pressure and since the
> register that contains the SYMBOL_REF is used only for these kind of
> addresses, it knocks off the REG and replaces it with the SYMBOL_REF
> itself.  But the problem is how to make it not do so.  Does it check
> the instruction predicates when it does this transformation in the
> IRA?  I feel it doesn't.  It just looks at the REG_EQUIV and REG_EQUAL
> expression lists and carries out the transformation based on that.

That is what it does for the transformation, yes, but it only commits
the transformation back to the RTL if it is valid.  At least that is how
it is supposed to work.

Ian

Re: Address rejected by TARGET_LEGITIMATE_ADDRESS_P recreated in post reload CSE pass at -O2

[Ayonam Ray]

On 23 May 2012 01:24, Ian Lance Taylor <iant@google.com> wrote:

>> It is exactly as you said.  I fixed my predicate for that instruction.
>>  So what was earlier a general_operand now checks for general_operand
>> and in addition, it checks for the operand to be a MEM (PLUS (MULT
>> (REG  CONST_INT))  SYMBOL_REF) and rejects those operands.
>
> I'm not sure I understand this, because it sounds like that MEM is
> already invalid and therefore not a general_operand.  When
> general_operand sees a MEM, it checks that the address satisfies the
> legitimate_address_p target hook, and I thought you indicated that such
> an address would fail that hook.

Oh! Yes, it didn't occur to me.  The routine
memory_address_addr_space_p() does that.

>> However, I still get the same problem.  What I noticed is that the
>> address conversion from using a REG instead of a SYMBOL_REF happens at
>> the IRA stage.  I presume it is having register pressure and since the
>> register that contains the SYMBOL_REF is used only for these kind of
>> addresses, it knocks off the REG and replaces it with the SYMBOL_REF
>> itself.  But the problem is how to make it not do so.  Does it check
>> the instruction predicates when it does this transformation in the
>> IRA?  I feel it doesn't.  It just looks at the REG_EQUIV and REG_EQUAL
>> expression lists and carries out the transformation based on that.
>
> That is what it does for the transformation, yes, but it only commits
> the transformation back to the RTL if it is valid.  At least that is how
> it is supposed to work.

Somehow, it doesn't do that.  In fact, a hint to such a possibility is
given in the comment para that immediately precedes the function
find_reload_address() in reload.c.  And again in the function
find_reloads() in reload.c around line 2770 (in version 4.5.3) wherein
it says the following:

<quote>
     Also here any references to pseudo regs that didn't get hard regs
     but are equivalent to constants get replaced in the insn itself
     with those constants.  Nobody will ever see them again.
<unquote>

I resolved this by implementing the target hook
LEGITIMIZE_RELOAD_ADDRESS wherein I check for a symbolic reference in
the two parts of a PLUS address and if I find so, I do a push_reload()
of that.  The code is not complete though since it does not handle the
many other types of addresses that might end up having a symbolic
reference.  But for now, it works.

Thanks for your help.
Regards
Ayonam