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>
Renato Golin via llvm-dev
2016-May-09 08:39 UTC
[llvm-dev] LLVM issuse:AArch64 TargetParser
On 9 May 2016 at 09:19, Jojo Ma <jojo.ma at linaro.org> wrote:> +//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; > +}Hi Jojo, With the TargetParser, the idea is to avoid that specific knowledge on the tools themselves, and moving all string parsing (startswith, StringSwitch) to the parser. But that creates the conundrum that we've seen, that we can't parse it uniquely without more context. It also seems that we need the Triple to be able to infer anything about march. That is the logic that needs to be in Clang, not the string parsing. Another alternative would be to create two checkValid functions, one explicitly for ARM and one for AArch64, and call them from different places in Clang. Hope that helps. cheers, --renato
Hi renato, With the TargetParser, the idea is to avoid that specific knowledge on> the tools themselves, and moving all string parsing (startswith, > StringSwitch) to the parser. > > But that creates the conundrum that we've seen, that we can't parse it > uniquely without more context. >This is just as a filter,it should not affect the context,I think. But in order to filter out the invalid arch, I have no idea how to avoid doing the string parsing in the tool for now. It also seems that we need the Triple> to be able to infer anything about march. That is the logic that needs > to be in Clang, not the string parsing.Feature parsing is done after the triple identified. As we can see below： static void getTargetFeatures(const ToolChain &TC, const llvm::Triple &Triple, const ArgList &Args, ArgStringList &CmdArgs, bool ForAS) { ... ... case llvm::Triple::arm: case llvm::Triple::armeb: case llvm::Triple::thumb: case llvm::Triple::thumbeb: getARMTargetFeatures(TC, Triple, Args, Features, ForAS); break; ... ... case llvm::Triple::aarch64: case llvm::Triple::aarch64_be: getAArch64TargetFeatures(D, Args, Features); break; ... ... } Another alternative would be to create two checkValid functions, one> explicitly for ARM and one for AArch64, and call them from different > places in Clang. >Yes, it will be more clear. Thank you very much! Renato. Regards, Jojo>On 9 May 2016 at 16:39, Renato Golin <renato.golin at linaro.org> wrote:> On 9 May 2016 at 09:19, Jojo Ma <jojo.ma at linaro.org> wrote: > > +//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; > > +} > > Hi Jojo, > > With the TargetParser, the idea is to avoid that specific knowledge on > the tools themselves, and moving all string parsing (startswith, > StringSwitch) to the parser. > > But that creates the conundrum that we've seen, that we can't parse it > uniquely without more context. It also seems that we need the Triple > to be able to infer anything about march. That is the logic that needs > to be in Clang, not the string parsing. > > Another alternative would be to create two checkValid functions, one > explicitly for ARM and one for AArch64, and call them from different > places in Clang. > > Hope that helps. > > cheers, > --renato >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160509/f8de084b/attachment-0001.html>