Renato Golin via llvm-dev
2016-May-05 16:16 UTC
[llvm-dev] 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>