<div dir="ltr"><div>Hi Bradley & Renato,<br><br></div><div>Thank you very much!<br></div><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span class="im">> Allowing -march=aarch64/arm64 is somewhat misleading I think, -march is used<br>
> for specifying an architecture version to target whereas aarch64/arm64 don’t<br>
> convey any information to that effect, does it mean armv8a, armv8.1-a, etc?<br>
</span><br>
That's a good point. But also, what does "armv8a" mean? AArch64? AArch32?<br>
<br>
I guess we could use the triple (which has aarch64 or arm in it), but<br>
then it will need the triple or else we'll have a problem, since the<br>
current interpretation of "armv8a" is AArch32.</blockquote><div><br></div><div><span style="color:rgb(0,0,255)"><span class="">I agree with you two. Using -march=aarch64/arm64 is a bit misleading,as Bradley said.</span><br><span class="">I did some tests on the things renato mentioned.Only when </span></span><span class=""><span style="color:rgb(0,0,255)"> we specified aarch64 in the triple,<br>-march=armv8+ be </span></span><span class=""><span style="color:rgb(0,0,255)"><strong class="">     </strong><span class=""><span>interpreted to</span></span> AArch64,otherwise AArch32.</span><br></span></div><div><span class=""><br></span><span class=""></span><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span class="im">> Personally I’m in favor of having that be rejected, it would be good to have<br>
> TargetParser/Clang generally reject CPUs/architectures that are not valid or<br>
> don’t add information as opposed to converting them to a fairly arbitrary<br>
> choice (that will and does only cause confusion).<br>
<br>
</span>Rejecting that on -march is independent than rejecting that in the<br>
target parser.<br>
<br>
I think the logic of refusing this or that "arch" string in this or<br>
that tool should be restricted to the tool, not the parser.<br>
<br>
Means, we still have to worry about the parser's ability to understand<br>
armv8+ with respect to AArch64 vs AArch32.<br>
<br>
I could suggest we use -m32/-m64, but I won't. :)</blockquote><div><br></div><div><span style="color:rgb(0,0,255)">Actually,I found there is a same problem for arm.For this case,I think maybe we can play a trick in the clang.<br><span class="">Checking whether the given arch valid or not,</span></span><span class=""><span style="color:rgb(0,0,255)">before we throw it to the parser,which can be used for both arm<br>and aarch64.</span><br></span></div></div><div> </div></div><div class="gmail_extra"><br><div class="gmail_quote">On 6 May 2016 at 00:16, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 5 May 2016 at 13:01, Bradley Smith <<a href="mailto:Bradley.Smith@arm.com">Bradley.Smith@arm.com</a>> wrote:<br>
> Allowing -march=aarch64/arm64 is somewhat misleading I think, -march is used<br>
> for specifying an architecture version to target whereas aarch64/arm64 don’t<br>
> convey any information to that effect, does it mean armv8a, armv8.1-a, etc?<br>
<br>
</span>Hi Bradley,<br>
<br>
That's a good point. But also, what does "armv8a" mean? AArch64? AArch32?<br>
<br>
I guess we could use the triple (which has aarch64 or arm in it), but<br>
then it will need the triple or else we'll have a problem, since the<br>
current interpretation of "armv8a" is AArch32.<br>
<span class=""><br>
<br>
> Personally I’m in favor of having that be rejected, it would be good to have<br>
> TargetParser/Clang generally reject CPUs/architectures that are not valid or<br>
> don’t add information as opposed to converting them to a fairly arbitrary<br>
> choice (that will and does only cause confusion).<br>
<br>
</span>Rejecting that on -march is independent than rejecting that in the<br>
target parser.<br>
<br>
I think the logic of refusing this or that "arch" string in this or<br>
that tool should be restricted to the tool, not the parser.<br>
<br>
Means, we still have to worry about the parser's ability to understand<br>
armv8+ with respect to AArch64 vs AArch32.<br>
<br>
I could suggest we use -m32/-m64, but I won't. :)<br>
<br>
cheers,<br>
--renato<br>
</blockquote></div><br></div>