This is the mail archive of the
mailing list for the GCC project.
Re: ping: [PATCH, ARM] attribute target (thumb,arm) [0-6]
- From: Ramana Radhakrishnan <ramana dot radhakrishnan at arm dot com>
- To: Christian Bruel <christian dot bruel at st dot com>
- Cc: Richard Earnshaw <Richard dot Earnshaw at arm dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 30 Apr 2015 11:00:00 +0100
- Subject: Re: ping: [PATCH, ARM] attribute target (thumb,arm) [0-6]
- Authentication-results: sourceware.org; auth=none
- References: <54D8A94E dot 3010603 at st dot com> <CAJA7tRZGiPVXpWj8i-eDpvsXXtVscCuaS_v-2XM4Zqv-R2Rccg at mail dot gmail dot com> <5534BA3F dot 8060602 at st dot com> <CAJA7tRbf1pM0t_-W91PBSprN3MXtJFgMhhz+5njwJecesBV0GQ at mail dot gmail dot com> <5541E962 dot 4090202 at st dot com>
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")))
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.
Yep - funnily enough if you remove "arm" and just use "fpu=vfpv4", I
think you get an error.
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
I can resurrect the inline check chunk. FYI, with a few small examples
arm/thumb attribute is correctly handled by LTO
Yes it would work with normal C code as it does normally - I'm worried
about functions with inline asm. We've just increased the inlining scope
with lto and that would mean things are a bit more painful ?
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).
Absolutely - I'd rather spend the time first in polishing this up.
Extending it for other options can be something you look at separately.
BTW I was pointed at a PR for this yesterday by a colleague -
So, lets use that as the PR for this work.