[PATCH] [AArch64] Add add/sub/cmp/cmn aliases to MC AsmParser

[Jim Grosbach]

> On Jul 11, 2014, at 3:14 PM, Arnaud A. de Grandmaison <arnaud.degrandmaison at arm.com> wrote:
> 
> Only the cmn -> adds / cmp -> subs aliases  are part of the ARM ARM.
> 
> The other aliases, in this patch or my previous patch, do not appear in the
> ARM ARM, because they are pseudos in ARM's parlance, i.e. cases that a
> compiler would not generate by itself, but that assemblers should accept,
> for compatibility between different assemblers. Those pseudos are used in
> already existing hand written assembly code : for example, the bic with
> immediate is used at several places in the linux kernel.
> 
> The goal  is to be able to assemble code which other assemblers do accept,
> so that users can switch fully to llvm for their toolchain. I do not know if
> such a compatibility document exists, so  let me check that ; but I agree
> that this  document is necessary so that there is an official , reasonable
> and documented common ground to support.

Cool. That documentation is exactly what I’m after, so sounds like we’re on the same page.

We’ve historically used the ARM ARM as the canonical reference of what the assembler should support, as it included the canonical instruction aliases and such that determine what the compiler should generate and the assembler should parse. I’d love to see, perhaps as an appendix, that expanded to include those aliases that an assembler is expected to accept but the compiler is not expected to produce in assembly output.

-Jim


> 
> Cheers,
> --
> Arnaud A. de Grandmaison
> 
> -----Original Message-----
> From: llvm-commits-bounces at cs.uiuc.edu
> [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Tim Northover
> Sent: 11 July 2014 22:39
> To: Renato Golin
> Cc: LLVM Commits
> Subject: Re: [PATCH] [AArch64] Add add/sub/cmp/cmn aliases to MC AsmParser
> 
>> It is possible that GCC already does that and maybe that's the reason 
>> for the patch? (Arnaud?)
> 
> That almost certainly is the direct reason. But ARM should be strongly
> encouraged to document it in the ARM ARM if it becomes some kind of de facto
> standard (assuming it's not there already).
> 
> Cheers.
> 
> Tim.
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 
> 
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits