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

[James]

Chandler Carruth-2 wrote
> On Sat, Oct 20, 2012 at 10:37 AM, Renato Golin <

> rengolin@

> > wrote:
>> On 19 October 2012 17:00, Duncan Sands <

> baldrick@

> > 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.

Why not move the ABI reasoning to the lowering stage instead, and simply 
specify which calling convention should be used in the function declaration?

The complex reasoning that's currently in clang to determine the placement 
of each parameter could be moved to LLVM and called in the lowering phase.

One problem as you say of course is that the ABI is tied to the language, 
and so some information is lost in the generation of the IR from the AST; 
i.e. it isn't obvious how to get an LLVM function back to what function / 
method / constructor it came from in the source language. 
However it wouldn't be impossible to attatch this needed information to 
the LLVM function when it's created so that the lowering code *can* have 
all the information it needs.

The big win for this approach is lowering the bar for new frontends using 
ABIs which have lowering code already written. Another is that language 
interoperability is made significantly easier: if I want to call some code 
from language X, then all I have to do is tell LLVM to use language X's 
calling convention for this function and specify what the declaration in X 
looks like. Instead, at the moment, I'd have to duplicate the ABI logic 
for X to determine what the declaration looks like for the particular target 
I'm compiling on. Similarly, if I'm in language X and want to expose 
some functions as a C functions, I don't need to know the details of the 
C ABI.

Food for thought anyway.
James



--
View this message in context: http://llvm.1065342.n5.nabble.com/How-to-represent-attribute-fastcall-functions-in-the-IL-tp50151p50218.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.