[llvm-dev] LLVM issuse:AArch64 TargetParser

[Bruce Hoult via llvm-dev]

Note that armv8a modifies the A32 and T32 instruction sets, and is
therefore an important -march option for 32 bit code. Therefore armv8a can
not be used to imply aarch64.

For example:

- IT predication instruction with more than a single controlled 16 bit
instruction, or an instruction that modifies PC is deprecated. All old uses
of IT work by default, but a control bit enables the OS to cause a trap on
use of a deprecated use.

- new A32 and T32 Load Acquire/Store Release instructions

- new A32 and T32 scalar FP instructions including conditional select, min,
max, new rounding modes for FP to int conversion, conversion between half
precision and double precision

- new A32 and T32 vector forms of the above FP operations

- new A32 and T32 cryptographic instructions

- changes to barrier instructions

Users can reasonably expect -march=armv8a for 32 bit code to potentially
generate the new FP instructions and restrict the use of the IT instruction.


On Thu, May 5, 2016 at 1:11 PM, Jojo Ma via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
> Hi everyone,
>
> I'm a member engineer of linaro's llvm team,coming from Spreadtrum.I am a
> new person on LLVM.Now I'm writing a Target Parser for AArch64,so options
> parsing of AArch64 about cpu & arch & fpu can be summary to one place.
>
> In the TargetParser,we assume "aarch64" and "arm64" are synonyms of
> armv8a(as they are only for armv8a,people usually do this). So after using
> AArch64TargetParser in options parsing in Clang,using "-march=aarch64" and
> "-march=arm64" are both valid.
>
> I saw Kevin has a different view on this in his submission:r213353.
>
>
>
> *+// RUN: %clang -target aarch64 -march=arm64 -### -c %s 2>&1 | FileCheck
> -check-prefix=CHECK-ARCH-NOT-ACCEPT %s+// RUN: %clang -target aarch64
> -march=aarch64 -### -c %s 2>&1 | FileCheck
> -check-prefix=CHECK-ARCH-NOT-ACCEPT %s+// CHECK-ARCH-NOT-ACCEPT: error: the
> clang compiler does not support*
>
> So I failed on the regression testing.So I think we should reach a
> consensus on this issue.
> Would you mind letting me know what you think of this issuse?
>
> Thank you very much!Looking forward to your reply!
> I enclose the attachments for your reference.
>
> Best Regards,
> Jojo.ma
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160518/5eccc6a5/attachment.html>