[patch, arm] Fix PR target/50305 (arm_legitimize_reload_address problem)

[Ramana Radhakrishnan]

On 26 September 2011 15:24, Ulrich Weigand <uweigand@de.ibm.com> wrote:
> Ramana Radhakrishnan wrote:
>> On 9 September 2011 18:04, Ulrich Weigand <uweigand@de.ibm.com> wrote:
>> >
>> > In theory, LEGITIMIZE_RELOAD_ADDRESS could attempt to handle them by
>> > substituting the equivalent constant and then reloading the result.
>> > However, this might need additional steps (pushing to the constant pool,
>> > reloading the constant pool address, ...) which would lead to significant
>> > duplication of code from core reload.  This doesn't seem worthwhile
>> > at this point ...
>>
>> Thinking about it a bit more after our conversation, we do have the
>> movw / movt instructions for armv7-a - why push this to the constant
>> pool if we can rematerialize it ?  Finding a way to use them rather
>> than pushing things out to the constant pool might be an interesting
>> experiment for later ..
>
> Reload common code will already choose whatever the best option is
> for reloading a constant, according to target hooks (legitimate_constant_p
> and preferred_reload_class); it doesn't always push to the constant pool.
> However, even on ARM there are currently certain cases where pushing to
> the pool is necessary (floating point; some constants involving symbols).
>

I see your point. I parsed your last mail as it gets into the constant
pool by default. If it does
that's a separate problem.


>
> Is this sufficient, or should I test any other set of options as well?

Could you run one set of tests with neon ?

>
>> Regarding the testcase - please add an -mfloat-abi=soft to the
>> testcase so that it tests the specific case that failed in case the
>> default configuration was with softfp.
>
> Just to clarify: in the presence of the other options that are already
> in dg-options, the test case now fails (with the unpatched compiler)
> for *any* setting of -mfloat-abi (hard, soft, or softfp).  Do you still
> want me to add a specific setting to the test case?

No the mfpu=vfpv3 is fine. Instead of skipping I was wondering if we
could prune the outputs to get this through all the testers we have.

Otherwise this is OK.

cheers
Ramana

>
> Thanks,
> Ulrich
>
> --
>  Dr. Ulrich Weigand
>  GNU Toolchain for Linux on System z and Cell BE
>  Ulrich.Weigand@de.ibm.com
>