llvm dev - May 2016 - LLVM issuse:AArch64 TargetParser

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

Hi Bradley & Renato,

Thank you very much!

> > 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?
>
> 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.

I agree with you two. Using -march=aarch64/arm64 is a bit misleading,as
Bradley said.
I did some tests on the things renato mentioned.Only when we specified
aarch64 in the triple,
-march=armv8+ be interpreted to AArch64,otherwise 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. :)

Actually,I found there is a same problem for arm.For this case,I think
maybe we can play a trick in the clang.
Checking whether the given arch valid or not,before we throw it to the
parser,which can be used for both arm
and aarch64.


On 6 May 2016 at 00:16, Renato Golin <renato.golin at linaro.org> wrote:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160506/b215297f/attachment.html>

Hi all,

Actually,I found there is a same problem for arm.For this case,I
think
> maybe we can play a trick in the clang.
> Checking whether the given arch valid or not,before we throw it to the
> parser,which can be used for both arm
> and aarch64.

For the actions I mentioned above,I wrote a check function as below, basing
on the naming rules of the arm architecture.

+//Only if -march startwith "armv" or "v" or
"iwmmxt" or "xscale",it can be
seen valid and sended to TargetParser
+//for further parsing
+static bool checkArchValid(StringRef Arch)
+{
+  if ((Arch.startswith("armv")) || Arch[0] == 'v' ||
+         (Arch.startswith("iwmmxt")) ||
(Arch.startswith("xscale")))
+    return true;
+  return false;
+}

I just do a simple check in clang.As the TargetParser will parse it in
detail,if passed.
If you have any suggestions, please let me know.Thank you very much!

Attachments are the newest patches.

Regards,
Jojo

On 6 May 2016 at 15:15, Jojo Ma <jojo.ma at linaro.org> wrote:
> Hi Bradley & Renato,
>
> Thank you very much!
>
>
>> > 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?
>>
>> 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.
>
>
> I agree with you two. Using -march=aarch64/arm64 is a bit misleading,as
> Bradley said.
> I did some tests on the things renato mentioned.Only when we specified
> aarch64 in the triple,
> -march=armv8+ be interpreted to AArch64,otherwise 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. :)
>
>
> Actually,I found there is a same problem for arm.For this case,I think
> maybe we can play a trick in the clang.
> Checking whether the given arch valid or not,before we throw it to the
> parser,which can be used for both arm
> and aarch64.
>
>
> On 6 May 2016 at 00:16, Renato Golin <renato.golin at linaro.org>
wrote:
>
>> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160509/8b445fb7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AArch64TargetParser_llvm.patch
Type: text/x-patch
Size: 32705 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160509/8b445fb7/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AArch64TargetParser_clang.patch
Type: text/x-patch
Size: 5366 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160509/8b445fb7/attachment-0001.bin>