This is the mail archive of the gcc-patches@gcc.gnu.org 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: ping: [PATCH, ARM] attribute target (thumb,arm) [0-6]



On 04/30/2015 09:43 AM, Ramana Radhakrishnan wrote:
> On Mon, Apr 20, 2015 at 9:35 AM, Christian Bruel <christian.bruel@st.com> wrote:
>> Hello Ramana
>>
>>>>
>>>
>>> Can you respin this now that we are in stage1 again ?
>>>
>>> Ramana
>>>
>>
>> Attached the rebased, rechecked set of patches. Original with comments
>> posted in
>>
>> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02455.html
>> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02458.html
>> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02460.html
>> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02461.html
>> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02463.html
>> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02467.html
>> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02468.html
>>
>> many thanks,
>>
>> Christian
> 
> 
> A general note, please reply to each of the patches with a rebased
> patch as a separate email. Further more all your patches appear to
> have dos line endings so they don't seem to apply cleanly. Please
> don't have spurious headers in your patch submission - it then makes
> it hard to , please create it in a way that it is easily applied by
> someone trying it out. It looks like p4 needs a respin as I got a
> reject trying to apply the documentation patch to my tree while trying
> to apply it.
> 

OK, thanks for the suggestions and sorry for the p4 reject. The sources
are moving fast and I have hard times catching up with re-bases.

> I tried the following decoration on foo in gcc.target/arm/attr_arm.c
> 
> 
> int __attribute__((target("arm, fpu=vfpv4")))
> foo(int a)
> {
>   return a ? 1 : 5;
> }
> 
> 
> And the compiler accepts it just fine.

Indeed, it's a mistake for now. attributes other the arm/thumb ones
shall be rejected (eventually with a "not yet implemented" warning for
the fpu, error for the others.) until we extend it.

> 
> Given that with LTO we are now using target attributes to decide
> inlining - I'm not convinced that the inline asm case goes away. In
> fact it only makes things worse so I'm almost convinced to forbid
> inlining from "arm" to "thumb" or vice-versa, which is a reversal of
> my earlier position. I hadn't twigged that LTO would reuse this
> infrastructure and it's probably simpler to prevent inlining in those
> cases.

I can resurrect the inline check chunk. FYI, with a few small examples
arm/thumb attribute is correctly handled by LTO

> 
> Thoughts ?
> 
> So in essence I'm still playing with this and would like to iterate
> towards a quick solution.
> 

thanks, that would be good if we could land the arm/thumb attribute and
start the fpu extensions separately. (I'm currently playing with
fpu=neon but it will take time to have something solid).

Christian

> Ramana
> 


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