This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: patch to build GCC for arm with LRA


Thanks for the review.  Here is the fixed self-contained patch to
enable LRA on AAarch32 and AArch64 (for those who want to give a try).
 I'm still working on the issues described previously and will send
rtlanal.c patch separately to prepare the move.


On 9 September 2013 01:23, Vladimir Makarov <> wrote:
> On 13-09-08 2:04 PM, Richard Sandiford wrote:
>> Yvan Roux <> writes:
>>> @@ -5786,7 +5796,11 @@ get_index_scale (const struct address_info *info)
>>>         && info->index_term == &XEXP (index, 0))
>>>       return INTVAL (XEXP (index, 1));
>>>   -  if (GET_CODE (index) == ASHIFT
>>> +  if ((GET_CODE (index) == ASHIFT
>>> +       || GET_CODE (index) == ASHIFTRT
>>> +       || GET_CODE (index) == LSHIFTRT
>>> +       || GET_CODE (index) == ROTATE
>>> +       || GET_CODE (index) == ROTATERT)
>>>         && CONST_INT_P (XEXP (index, 1))
>>>         && info->index_term == &XEXP (index, 0))
>>>       return (HOST_WIDE_INT) 1 << INTVAL (XEXP (index, 1));
>> This bit doesn't look right.  The scale is only 1 << N for (ashift ... N).
>> I think we have to stick to returning zero for the other codes.
> Thanks, Richard.  I missed this.
> I am agree it might be a problem although the probability of it is
> negligible as index reg hardly can be equivalent to something + constant
> displacement (except may be case reg+reg when each reg can be base or index
> but in this case we don't use shifts).  Still returning zero is a safe
> solution as it prevents such equivalence substitution completely.
> Yvan, could modify this part of code and resend it to Richard Henderson for
> approval.
>> The other two (snipped) rtlanal.c hunks like fine to me FWIW.  Maybe now
>> would be a good time to add an "is this a shift code?" predicate though,
>> if we don't have one already.
> Yes, I think we could somehow to promote this info to LRA but I don't think
> it is necessary or urgent.  There is already an alternative solution -- just
> doing nothing as prohibiting equivalence substitution for complicated index
> part hardly worsens the generated code.

Attachment: arm-lra.patch
Description: Binary data

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]