[cfe-dev] ARM procedure calls (sorry)

Mon Aug 22 13:51:51 PDT 2016

>From Simon's email:
> I've forwarded this message onto Daniel as he is no longer with
Imagination
> Technologies.

Thanks.

>From Renato's email:
> 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.

The new Debian mips64el port hit this problem recently and is currently
carrying a small patch to change a default for their triple. I was planning
to suggest something that would bring such patches upstream but I decided
to wait until my latest set of triple patches were upstream before adding
another element to an already complicated problem.

The gist of that plan is to attach such distribution specific behaviour to
vendored triples and allow distributions to map their distribution triple
to their preferred vendored triple in LLVM. The overall effect is that
distributions get the ability to control the defaults of their native
compilers like they do for gcc but LLVM's ability to cross-compile to
anything is preserved.

On Mon, Aug 22, 2016 at 4:01 PM, Simon Dardis <Simon.Dardis at imgtec.com>
wrote:

>
>
> > -----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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160822/14ec907d/attachment.html>