This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, ARM, LRA] Prepare ARM build with LRA
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Eric Botcazou <ebotcazou at adacore dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Yvan Roux <yvan dot roux at linaro dot org>, Vladimir Makarov <vmakarov at redhat dot com>, Richard Earnshaw <rearnsha at arm dot com>, Marcus Shawcroft <marcus dot shawcroft at arm dot com>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>, Matthew Gretton-Dann <matthew dot gretton-dann at linaro dot org>, Patch Tracking <patches at linaro dot org>, Richard Henderson <rth at redhat dot com>
- Date: Wed, 25 Sep 2013 22:01:49 +0100
- Subject: Re: [PATCH, ARM, LRA] Prepare ARM build with LRA
- Authentication-results: sourceware.org; auth=none
- References: <CAD57uCfrF9Ns=jghNJOD07p5wg+_zcTc6wmfOknau3iSg4FvWg at mail dot gmail dot com> <2645374 dot 4NZeFxJkzv at polaris> <87bo3igoss dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <1623242 dot BDHJTW32D4 at polaris>
Eric Botcazou <ebotcazou@adacore.com> writes:
>> FWIW, I'd prefer to keep it as-is, since must_be_base_p (x) and
>> must_be_index_p (x) don't imply that we should look specifically at
>> XEXP (x, 0) (rather than just X, or XEXP (x, 1), etc.). I think it's
>> better to keep the code tests and the associated XEXPs together.
>
> Feel free to revert this part, but then add appropriate comments explaining
> why we are interested in LO_SUM for set_address_base and in MULT and the 5
> others for set_address_index. If it's because the former is rather a base
> than an index and vice-versa for the latter, then it's even clearer with the
> predicates I think.
The idea is that must_be_base_p and must_be_index_p are used when deciding
how to classify the operands of a PLUS. set_address_base and set_address_index
are called once we've decided which is which and want to record the choice.
There's no backing out by that stage.
So in the set_* routines it isn't about whether the value is definitely
a base or a definitely an index. It's just about drilling down through
what we've already decided is a base or index to get the inner reg or mem,
and knowing which XEXPs to look at. We could instead have used a for_each_rtx,
or something like that, without any code checks. But I wanted to be precise
about the types of address we allow, so that we can assert for things we
don't understand. In other words, it was "designed" to require the kind
of extension Yvan is adding here.
E.g. although it's a bit of a stretch, it might be in future that
someone wants to allow NOT in an index. It would then make sense
to add NOT to must_be_index_p. But the existing check:
if ((GET_CODE (*inner) == MULT || GET_CODE (*inner) == ASHIFT)
&& CONSTANT_P (XEXP (*inner, 1)))
inner = strip_address_mutations (&XEXP (*inner, 0));
wouldn't make sense as:
if (must_be_index_p (*inner) && CONSTANT_P (XEXP (*inner, 1)))
inner = strip_address_mutations (&XEXP (*inner, 0));
in that case, since NOT only has one operand. And it might be that
the NOT is allowed only outside the scale, only inside the scale,
or in both positions.
Not the best example, sorry.
Thanks,
Richard