<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" style="font-size:12pt; color:#000000; background-color:#FFFFFF; font-family:Calibri,Arial,Helvetica,sans-serif">
<p>Tim, Renato</p>
<p><br>
</p>
<p>Thanks to you both, <span style="font-size:12pt">I will go back to </span><span style="font-size:12pt">LLVM and see how I get on allowing SimplifyLibCalls to operate on aapcs calls. On a related note, are there any plans to enable Clang to use the backends
for target information? There seems to be a lot of mess and duplication which is bound to cause issues at some point.</span></p>
<p><span style="font-size:12pt"><br>
</span></p>
<p><span style="font-size:12pt">Thanks again,</span></p>
<p><span style="font-size:12pt">sam</span></p>
<p><br>
</p>
<div id="x_Signature">
<div id="x_divtagdefaultwrapper" style="font-size:12pt; color:#000000; background-color:#FFFFFF; font-family:Calibri,Arial,Helvetica,sans-serif">
<p>Sam Parker</p>
<p>Software Engineer, Compilation Tools</p>
<p>Development Solutions Group</p>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Tim Northover <t.p.northover@gmail.com><br>
<b>Sent:</b> 20 August 2016 17:42:47<br>
<b>To:</b> Sam Parker<br>
<b>Cc:</b> cfe-dev@lists.llvm.org; nd<br>
<b>Subject:</b> Re: [cfe-dev] ARM procedure calls (sorry)</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">On 18 August 2016 at 08:23, Sam Parker via cfe-dev<br>
<cfe-dev@lists.llvm.org> wrote:<br>
> (1) why is does the behaviour differ between -mfloat=hard and eabihf targets<br>
<br>
There are three separate components to determine this part of the ABI:<br>
<br>
1. The triple<br>
2. Explicit CC attribute overrides.<br>
3. Some weird "-float-abi" backend option.<br>
<br>
Clang's current policy is to emit Modules that work with either<br>
-float-abi=default or the explicitly specified float-abi: the checks<br>
are basically, "if -float-abi is changing something implicitly, mark<br>
that in the IR with CC attrs too".<br>
<br>
As Renato says, I think this is necessary for things like LTO to work<br>
(where the final link step runs under -float-abi=default I think).<br>
<br>
> I'm looking to allow LLVM to simplify more library calls and it appears that currently this cannot happen for functions that are declared with a call standard other than C.<br>
<br>
This is a really tricky one. My first intuition is that in an<br>
"arm-none-eabi -mfloat-abi=hard" environment, you'd expect the C & C++<br>
standard libraries to be soft-float (otherwise isn't it really<br>
arm-none-eabihf?). We get this wrong now: "float foo(float *in) {<br>
return floorf(*in); }" uses hard-float.<br>
<br>
But even if that's true, how does Clang know what's standard library<br>
and what's not (e.g. POSIXy stuff might count)? And should it be in<br>
the business of silently modifying declarations like that if it did?<br>
You could argue that a library intending to be compatible with both<br>
-mfloat-abi=hard and the default should annotate its functions with<br>
__attribute__((pcs("aapcs"))). But you could also argue that's a<br>
ridiculously onerous burden to put on library writers.<br>
<br>
I've got no good answers to any of those issues yet.<br>
<br>
However, to the extent that AAPCS, AAPCS_VFP and C are compatible<br>
under the given triple (careful, they're not on iOS), I think LLVM IR<br>
probably allows them to be intermixed. So you could probably<br>
legitimately optimize integer/pointer libcalls even with the<br>
mismatching CC.<br>
<br>
Tim.<br>
<br>
</div>
</span></font>
</body>
</html>