[cfe-dev] ARM procedure calls (sorry)

[Tim Northover via cfe-dev]

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.