This is the mail archive of the
mailing list for the GCC project.
Re: [ARM] Is TARGET_UNIFIED_ASM still needed?
- From: Kyrill Tkachov <kyrylo dot tkachov at arm dot com>
- To: Richard Earnshaw <Richard dot Earnshaw at arm dot com>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 23 Jul 2014 09:59:49 +0100
- Subject: Re: [ARM] Is TARGET_UNIFIED_ASM still needed?
- Authentication-results: sourceware.org; auth=none
- References: <53CE63D1 dot 4010000 at arm dot com> <53CE81F5 dot 8070209 at arm dot com> <53CF7866 dot 9070707 at arm dot com>
On 23/07/14 09:55, Richard Earnshaw wrote:
On 22/07/14 16:23, Ramana Radhakrishnan wrote:
On 22/07/14 14:14, Kyrill Tkachov wrote:
In the arm backend we've got this TARGET_UNIFIED_ASM macro that is
currently on for TARGET_THUMB2 with a comment that says:
/* We could use unified syntax for arm mode, but for now we just use it
for Thumb-2. */
I've been doing some work converting the pre-UAL floating point
mnemonics to unified syntax and it seems if we were to strictly adhere
to this TARGET_UNIFIED_ASM I would have to guard those changes, which
would be somewhat ugly.
I would just change vfp.md to UAL and expect it to work because GAS
accepts unified syntax for the floating point instructions even without
We need T_U_A until the point of time that the Thumb1 port is converted
to UAL, GAS validated against Thumb1 and the rest of the "arm" port is
converted to UAL and verified with GAS.
Additionally if someone were to do the full transition, remember that
users need to have a way of mixing non-unified syntax in inline
assembler with unified syntax in the rest of the C code.
Is it perhaps time to just drop this and assume unified asm everywhere?
We also need to be able to support User's inline assembly that is not in
unified syntax. Though that might be a different issue to the one
you're trying to address here.
Thanks for the responses,
I was just thinking that the TARGET_UNIFIED_ASM macro is not honored
right now anyway (due to the pre-UAL mnemonics in vfp.md) so we might
want to get rid of it. I don't think this would be a user-visible
change, now would it reject pre-UAL inline assembly from what I can see
in its uses.