[llvm-dev] LLVM issuse:AArch64 TargetParser
Bruce Hoult via llvm-dev
llvm-dev at lists.llvm.org
Wed May 18 05:17:05 PDT 2016
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.
- 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,
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev