[ARM] Big Endian and Generic tuning

My recent patch to add -mcpu=generic-armv7-a omitted support for big 
endian. This patch should solve that.

As far as I know the only this missing is the linker spec. (I have no 
big-endian targets to test with.)

OK?

Andrew

On 25/10/11 11:51, Andrew Stubbs wrote:
> My recent patch to add -mcpu=generic-armv7-a omitted support for big 
> endian. This patch should solve that.
> 
> As far as I know the only this missing is the linker spec. (I have no 
> big-endian targets to test with.)
> 
> OK?
> 
> Andrew
> 
> 
> be.patch
> 
> 
> 2011-10-25  Andrew Stubbs  <ams@codesourcery.com>
> 
> 	gcc/
> 	* config/arm/bpabi.h (BE8_LINK_SPEC): Recognize generic-armv7 tuning.
> 
> --- a/gcc/config/arm/bpabi.h
> +++ b/gcc/config/arm/bpabi.h
> @@ -58,6 +58,7 @@
>  #define BE8_LINK_SPEC \
>    " %{mbig-endian:%{march=armv7-a|mcpu=cortex-a5	\
>     |mcpu=cortex-a8|mcpu=cortex-a9|mcpu=cortex-a15	\
> +   |mcpu=generic-armv7*					\
>     |march=armv7-m|mcpu=cortex-m3			\
>     |march=armv7e-m|mcpu=cortex-m4			\
>     |march=armv6-m|mcpu=cortex-m0			\


Hmm, just thought.  Shouldn't this be generic-armv7-a and not generic-armv7?

A generic armv7 implies (to me) code that will run on all variants of
armv7, which includes both R and M profiles.

R.

On 25/10/11 13:19, Richard Earnshaw wrote:
>> 2011-10-25  Andrew Stubbs<ams@codesourcery.com>
>>
>> 	gcc/
>> 	* config/arm/bpabi.h (BE8_LINK_SPEC): Recognize generic-armv7 tuning.
>>
>> --- a/gcc/config/arm/bpabi.h
>> +++ b/gcc/config/arm/bpabi.h
>> @@ -58,6 +58,7 @@
>>   #define BE8_LINK_SPEC \
>>     " %{mbig-endian:%{march=armv7-a|mcpu=cortex-a5	\
>>      |mcpu=cortex-a8|mcpu=cortex-a9|mcpu=cortex-a15	\
>> +   |mcpu=generic-armv7*					\
>>      |march=armv7-m|mcpu=cortex-m3			\
>>      |march=armv7e-m|mcpu=cortex-m4			\
>>      |march=armv6-m|mcpu=cortex-m0			\
>
>
> Hmm, just thought.  Shouldn't this be generic-armv7-a and not generic-armv7?
>
> A generic armv7 implies (to me) code that will run on all variants of
> armv7, which includes both R and M profiles.

The actual option is indeed -mcpu=generic-armv7-a, but I thought I might 
as well wildcard it since this option appears to apply to all the 
profiles, and I couldn't really see why all the existing contents should 
all be listed individually (I mean, this patch proves that doing so is a 
maintenance burden, even if in this case it wouldn't have helped).

Having said that, I now see it doesn't list any R-profile options. Is 
that because it doesn't apply, or because there are just missing?

I can certainly make this patch A-profile specific if this is wrong.

Andrew

On 25/10/11 13:48, Andrew Stubbs wrote:
> On 25/10/11 13:19, Richard Earnshaw wrote:
>>> 2011-10-25  Andrew Stubbs<ams@codesourcery.com>
>>>
>>> 	gcc/
>>> 	* config/arm/bpabi.h (BE8_LINK_SPEC): Recognize generic-armv7 tuning.
>>>
>>> --- a/gcc/config/arm/bpabi.h
>>> +++ b/gcc/config/arm/bpabi.h
>>> @@ -58,6 +58,7 @@
>>>   #define BE8_LINK_SPEC \
>>>     " %{mbig-endian:%{march=armv7-a|mcpu=cortex-a5	\
>>>      |mcpu=cortex-a8|mcpu=cortex-a9|mcpu=cortex-a15	\
>>> +   |mcpu=generic-armv7*					\
>>>      |march=armv7-m|mcpu=cortex-m3			\
>>>      |march=armv7e-m|mcpu=cortex-m4			\
>>>      |march=armv6-m|mcpu=cortex-m0			\
>>
>>
>> Hmm, just thought.  Shouldn't this be generic-armv7-a and not generic-armv7?
>>
>> A generic armv7 implies (to me) code that will run on all variants of
>> armv7, which includes both R and M profiles.
> 
> The actual option is indeed -mcpu=generic-armv7-a, but I thought I might 
> as well wildcard it since this option appears to apply to all the 
> profiles, and I couldn't really see why all the existing contents should 
> all be listed individually (I mean, this patch proves that doing so is a 
> maintenance burden, even if in this case it wouldn't have helped).
> 
> Having said that, I now see it doesn't list any R-profile options. Is 
> that because it doesn't apply, or because there are just missing?
> 
> I can certainly make this patch A-profile specific if this is wrong.
> 
> Andrew
> 


The difficulty on R profile is that although BE-32 mode is obsolete,
there is a config bit that can be set to make the CPU byte-swap the
instruction stream to make it behave largely like it is running in BE-32
mode.

I think really we should be pushing the R-profile code towards having
BE-8 as the default; but to do that we really need a compiler option
that can override this behaviour (probably -mbe-[8|32]).  Once we have
that option, we can fix the compiler to prefer BE-8 as there is then a
way to get back the legacy behaviour.


R.