[cfe-dev] ARM procedure calls (sorry)

[Simon Dardis via cfe-dev]

> -----Original Message-----
> From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of Renato
> Golin via cfe-dev
> Sent: 22 August 2016 13:55
> To: Sam Parker
> Cc: Daniel Sanders; nd; cfe-dev at lists.llvm.org
> Subject: Re: [cfe-dev] ARM procedure calls (sorry)
> 
> 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.

Yes, Daniel developed a series of patches that brought the Mips backend into
line with some of the other targets by modifying the triple for Mips to carry
ABI information. (I will taking over that patch series).

Our goal there was to be able to distinguish at the relevant places what ABI
was in use, as certain targets have the same triple but different ABI.

I've forwarded this message onto Daniel as he is no longer with Imagination
Technologies.

Thanks,
Simon

> 
> 
> > 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
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev