llvm dev - May 2016 - LLVM issuse:AArch64 TargetParser

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160505/a1278573/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AArch64TargetParser_clang.patch
Type: text/x-patch
Size: 4282 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160505/a1278573/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AArch64TargetParser_llvm.patch
Type: text/x-patch
Size: 32707 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160505/a1278573/attachment-0003.bin>

Hi,

Allowing -march=aarch64/arm64 is somewhat misleading I think, -march is used for
specifying an architecture version to target whereas aarch64/arm64 don’t convey
any information to that effect, does it mean armv8a, armv8.1-a, etc? Personally
I’m in favor of having that be rejected, it would be good to have
TargetParser/Clang generally reject CPUs/architectures that are not valid or
don’t add information as opposed to converting them to a fairly arbitrary choice
(that will and does only cause confusion).

Regards,
Bradley Smith

From: Jojo Ma [mailto:jojo.ma at linaro.org]
Sent: 05 May 2016 11:12
To: Bradley Smith; James Molloy; Kevin Qin
Cc: Renato Golin; llvm-dev at lists.llvm.org
Subject: LLVM issuse:AArch64 TargetParser


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160505/4c3ca113/attachment.html>

On 5 May 2016 at 13:01, Bradley Smith <Bradley.Smith at arm.com>
wrote:
> Allowing -march=aarch64/arm64 is somewhat misleading I think, -march is
used
> for specifying an architecture version to target whereas aarch64/arm64
don’t
> convey any information to that effect, does it mean armv8a, armv8.1-a, etc?
Hi Bradley,

That's a good point. But also, what does "armv8a" mean? AArch64?
AArch32?

I guess we could use the triple (which has aarch64 or arm in it), but
then it will need the triple or else we'll have a problem, since the
current interpretation of "armv8a" is AArch32.

> Personally I’m in favor of having that be rejected, it would be good to
have
> TargetParser/Clang generally reject CPUs/architectures that are not valid
or
> don’t add information as opposed to converting them to a fairly arbitrary
> choice (that will and does only cause confusion).
Rejecting that on -march is independent than rejecting that in the
target parser.

I think the logic of refusing this or that "arch" string in this or
that tool should be restricted to the tool, not the parser.

Means, we still have to worry about the parser's ability to understand
armv8+ with respect to AArch64 vs AArch32.

I could suggest we use -m32/-m64, but I won't. :)

cheers,
--renato

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>

Hi,

A64 versus A32/T32 code generation is controlled by the -target option which I
don’t believe is under discussion here.

James
On 18 May 2016, at 13:17, Bruce Hoult <bruce at hoult.org<mailto:bruce at
hoult.org>> wrote:

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<mailto: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<http://Jojo.ma>

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev



IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160518/0b0e5c74/attachment-0001.html>