
<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">

<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>

</head>

<body dir="ltr">

<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">

<p style="margin-top:0;margin-bottom:0"></p>

<div>Hi Peter,<br>

<br>

>> I think what Renato was meaning was that some CPUs already imply an<br>

>> FPU and hence -mfpu is already "kind of" auto. For example<br>

>> -mcpu=cortex-m4 implies a FPU.<br>

>> ARM_CPU_NAME("cortex-m4", ARMV7EM, FK_FPV4_SP_D16, true, ARM::AEK_NONE)<br>

<br>

Ok I understand now, I'm mixing up current and (possible) future features.<br>

<br>

>> clang -mcpu cortex-a8 -mfpu vfp4 -mfpu auto ->defaults back to VFP3.<br>

<br>

We would want to keep the current logic here. Which I've observed to be that the last mfpu wins, overriding the default from mcpu.<br>

<br>

$ ./clang --target=arm-arm-none-eabi -mcpu=cortex-a8 -mfpu=vfpv4-d16 -mfpu=vfpv4 -c /tmp/test.c -o /tmp/test.o -###<br>

<...> "-target-feature" "-d16" "-target-feature" "+vfp4" <...><br>

$ ./clang --target=arm-arm-none-eabi -mcpu=cortex-a8 -mfpu=vfpv4 -mfpu=vfpv4-d16 -c /tmp/test.c -o /tmp/test.o -###<br>

<...> "-target-feature" "+d16" "-target-feature" "+vfp4" <...><br>

(vfp4-d16 wins)<br>

<br>

So yes, with the explicit 'auto' you'd revert to the cpu provided fpu:<br>

<br>

$ ./clang --target=arm-arm-none-eabi -mcpu=cortex-a8 -mfpu=vfpv4 -mfpu=auto -c /tmp/test.c -o /tmp/test.o -###<br>

<...> "-target-feature" "-d16" "-target-feature" "+vfp3" <...><br>

<br>

(and without the 'auto' we'd emit a warning telling you that you overrode the 'vfpv3' from mcpu with 'vfpv4' from mfpu)<br>

<br>

>> but it illustrates that there may be other projects that would be affected if we are too strict.<br>

<br>

Definitely going to tread lightly when introducing new checks. Just having the option to enable them is a good place to start.<br>

<br>

Thanks,<br>

David Spickett.</div>

<br>

<p></p>

</div>

<hr style="display:inline-block;width:98%" tabindex="-1">

<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Peter Smith <peter.smith@linaro.org><br>

<b>Sent:</b> 26 September 2018 12:38:16<br>

<b>To:</b> David Spickett<br>

<b>Cc:</b> Renato Golin; llvm-dev; nd; Clang Dev<br>

<b>Subject:</b> Re: [llvm-dev] [RFC] New Clang target selection options for ARM/AArch64</font>

<div> </div>

</div>

<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">

<div class="PlainText">Hello David,<br>

<br>

Not a lot to add over what Eli and Renato have already mentioned.<br>

<br>

> 'auto' FPU value (Renato)<br>

> ================<br>

><br>

> >> I'd have assumed -mfpu is already "auto" by default. Or is this to<br>

> >> just override a previous option?<br>

> >><br>

> >> ex: clang -mcpu cortex-a8 -mfpu vfp4 -mfpu auto -> defaults back to VFP3.<br>

><br>

> I don't see any reference to this in the code or the docs, and clang something similair:<br>

> ./clang --target=arm-arm-none-eabi -mcpu=cortex-a8 -mfpu=vfp4 -mfpu=auto -c /tmp/test.c<br>

> clang-8: error: the clang compiler does not support '-mfpu=auto'<br>

><br>

> Maybe I'm missing something.<br>

><br>

<br>

I think what Renato was meaning was that some CPUs already imply an<br>

FPU and hence -mfpu is already "kind of" auto. For example<br>

-mcpu=cortex-m4 implies a FPU.<br>

ARM_CPU_NAME("cortex-m4", ARMV7EM, FK_FPV4_SP_D16, true, ARM::AEK_NONE)<br>

<br>

I think the example "clang -mcpu cortex-a8 -mfpu vfp4 -mfpu auto -><br>

defaults back to VFP3." was a theoretical what if -mfpu=auto came<br>

after an explicit -mpfu=vfp4, would this result in the default fpu<br>

thus overriding the previous -mfpu=vfp4<br>

<br>

> >> Define "incompatible". Older Arm cores could have new features that<br>

> wasn't even define in its own standard because manufacturers upgraded<br>

> the extra but not the core.<br>

><br>

> Good point, I suppose "incompatible" in the way I wrote it means "not listed as an off the shelf config". Which you're right, doesn't cover everything. So yes, agreed on defaulting to warnings behind -Wall.<br>

><br>

I think that post-cortex CPUs are far more locked down in terms of<br>

configurations. If you have an FPU it will always be of the same type.<br>

I agree with Renato that the outside world is considerably messier<br>

than we'd like though. For example compiler-rt builtins for Cortex-m4<br>

currently cheats and specifies a full double precision FPU as there<br>

are some functions (never called and hence never included in a M4<br>

binary but present in the archive) that use double precision floating<br>

point. In compiler-rt's case I think that we should fix that but it<br>

illustrates that there may be other projects that would be affected if<br>

we are too strict.<br>

<br>

Looking forward to seeing the results of the work.<br>

<br>

Peter<br>

</div>

</span></font></div>

</body>

</html>