[cfe-dev] ARM procedure calls (sorry)

[Sam Parker via cfe-dev]

Tim, Renato


Thanks to you both, I will go back to 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.


Thanks again,

sam


Sam Parker

Software Engineer, Compilation Tools

Development Solutions Group

________________________________
From: Tim Northover <t.p.northover at gmail.com>
Sent: 20 August 2016 17:42:47
To: Sam Parker
Cc: cfe-dev at lists.llvm.org; nd
Subject: Re: [cfe-dev] ARM procedure calls (sorry)

On 18 August 2016 at 08:23, Sam Parker via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> (1) why is does the behaviour differ between -mfloat=hard and eabihf targets

There are three separate components to determine this part of the ABI:

1. The triple
2. Explicit CC attribute overrides.
3. Some weird "-float-abi" backend option.

Clang's current policy is to emit Modules that work with either
-float-abi=default or the explicitly specified float-abi: the checks
are basically, "if -float-abi is changing something implicitly, mark
that in the IR with CC attrs too".

As Renato says, I think this is necessary for things like LTO to work
(where the final link step runs under -float-abi=default I think).

> 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.

This is a really tricky one. My first intuition is that in an
"arm-none-eabi -mfloat-abi=hard" environment, you'd expect the C & C++
standard libraries to be soft-float (otherwise isn't it really
arm-none-eabihf?). We get this wrong now: "float foo(float *in) {
return floorf(*in); }" uses hard-float.

But even if that's true, how does Clang know what's standard library
and what's not (e.g. POSIXy stuff might count)? And should it be in
the business of silently modifying declarations like that if it did?
You could argue that a library intending to be compatible with both
-mfloat-abi=hard and the default should annotate its functions with
__attribute__((pcs("aapcs"))). But you could also argue that's a
ridiculously onerous burden to put on library writers.

I've got no good answers to any of those issues yet.

However, to the extent that AAPCS, AAPCS_VFP and C are compatible
under the given triple (careful, they're not on iOS), I think LLVM IR
probably allows them to be intermixed. So you could probably
legitimately optimize integer/pointer libcalls even with the
mismatching CC.

Tim.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160822/627b519f/attachment.html>