[cfe-dev] ARM procedure calls (sorry)

[Renato Golin via cfe-dev]

On 22 August 2016 at 13:13, Sam Parker <Sam.Parker at arm.com> wrote:
> Well the code I was looking at was making assumptions about what the backend
> will decide about procedure calls, so why not ask the backend?

Exposing back-end information to the front-end is a pandora's box. You
can start naive and only ask what you really need to know, and then
people will be using for all sorts of little quirks and suddenly the
IR generated by Clang will be in a tight contract with what each LLVM
back-end can consume (aka. high coupling).

The way we do today, for better or worse, is to have the Triple class
expose all information front-ends need to know. This is far from
perfect, but if you want to make that relationship more coese, I
suggest you look into the Triple class.

One of the recent efforts by Daniel Sanders to re-factor the Triple
class was a way to fix that madness in the Mips back-end, which is
somewhat similar to ARM's. If you want to look into that, I suggest
you contact Daniel and Eric (CC's), as there was a lot of discussions
around design and behaviour.


> I haven't looked at the target classes in Clang in a long time, but just having a
> quick look now there still appears to be duplication with LLVM's target
> machine and subtargets, at least for ARM anyway.

Most of the target knowledge in Clang uses the Triple already, and
they're mostly concerning themselves with front-end stuff, which is
what we want. The meaning of triples and flags play a different part
in all this...


> For instance, the triple is
> used for ABI and data layout calculations and there's no end of flags for
> features. I guess I must be missing something, but it just seems odd and
> harder to maintain having two descriptions of the targets.

This is, unfortunately, a *requirement*. And a bad one at that.

In the GNU world, the triple is mostly descriptive, and the build-time
configure options are what really define behaviour. So each
distribution (of Linux, Mac, BSD) has done their own ways. Most of the
time, they have also chosen their own "different" triples, but not
always.

In the LLVM world, we don't have build-time options, so *all* logic
has to be in triples and command line options. Most of the time that
works because the triples are all slightly different, but they're not
always, and sometimes we either get things wrong, or we can't
represent something that GCC can with build-time options.

Using target options won't help, since the target class doesn't know
which system it's running and which ABI is should default to or fall
back to, etc. So, if we keep all that logic in the Triple, which is an
LLVM class and *has* access to the target information, we *can*
perform a proxy pattern from the real target information to the
front-ends without perverting the encapsulation.

Maybe, the simplest way to fix this mess is to enhance the Triple
class to have more target knowledge, so we can make sure that whatever
Clang interprets as "arm-none-eabi" is the exact same thing the
back-end will when it sees it in the IR.

We're probably pretty close, even it mostly by accident. However,
making it clearer won't be a bad move.

cheers,
--renato