[LLVMdev] How to represent __attribute__((fastcall)) functions in the IL

[Chandler Carruth]

On Sat, Oct 20, 2012 at 10:37 AM, Renato Golin <rengolin at systemcall.org> wrote:
> On 19 October 2012 17:00, Duncan Sands <baldrick at free.fr> wrote:
>> That said, I also don't like the idea of filling the IR with tons of target
>> specific stuff.
>
> In this case, I think it's even worse than "aapcs" or "fastcall", that
> are target dependent, but at a higher level.
>
> Proposing at which register each variable will be, forces the
> front-ends to know all about all targets LLVM supports (the register
> names for x86_64 will be different than for x86, which will be
> different than ARM, Thumb, MIPS, etc). Which is not just a
> language/ABI issue, but hardware architecture one.

I don't really disagree with anyone who finds this a bit distasteful,
but understand that we are already in an even worse situation.

The frontend must in fact reason in extreme detail about the targets
that LLVM supports, and these frontends already have the exact
register positioning (if not naming) encoded in them.

In addition, frontends must currently reason about exactly how each
target in LLVM will choose to lower various arguments and return
values of various types, and try to conjure up an LLVM type and
parameter distribution which each target will lower into the exact
registers which are mandated by the ABI for that target.

So the situation today is that frontends have all of this
target-specific information *and* there is an implicit, unspecified
contract between the frontend, LLVM's IR, and each target backend
about exactly how the lowering through these will occur in order to
ensure that the actual code generated matches the ABI requirements the
frontend is trying to encode. :: sigh ::


While in theory, I would love it if the frontends could be unaware of
such details, it seems impractical. The ABI is really tho combination
of language and target, whether we like it or not. I think we just
need a model for explicitly describing the required lowering, and
hopefully in a way orthogonal to the LLVM IR type system so that we
don't have to waste large amounts of IR complexity on shoving bits
into and out of peculiar IR types.

Unfortunately, I have no such concrete design in mind, and I certainly
still think that the onstack thing is a step in the right direction.

-Chandler

>
> Having the PCSBuilder / PCS pass, would decouple the front-end of the
> back-end, at least on PCS matters.
>
> However, I agree with you that we should not have function signatures
> that are different than their calls.
>
> --
> cheers,
> --renato
>
> http://systemcall.org/