llvm dev - Oct 2012 - [LLVMdev] How to represent __attribute__((fastcall)) functions in the IL

On 19 October 2012 16:40, Chandler Carruth <chandlerc at google.com>
wrote:
> Don't get me wrong, I don't have any good ideas about how to do
this, I'm
> just hoping someone does. End result might allow something like:
>
> declare void @foo(double inreg <eax,edx> %x)
Hi Chandler,

We were discussing about this on the Cambridge LLVM Social a while
ago, and we felt that there were far too much target dependent stuff
in the procedure call standards as it is.

Our approach would be to have a PCS layer, either in the front-end or
as a pass, that would know about both language and target to be able
to construct calls as the target is expecting (ABI-wise).

David Chisnall proposed a PCSBuilder (similar to IRBuilder, for
building function calls), where you just pass the basic info (return
type, arguments, flags, name) and it builds the function for you,
mangling names, changing parameters and assigning things to registers
when the ABI is less than helpful, possibly having an inreg syntax
like you describe.

My idea was to make it a pass, so you could delay the PCS mess up to a
later stage, when possibly you'd already have more information about
the target, but that's not necessarily true and might open the can of
worms that is having a multi-layered IR. For simplicity, we might
consider David's approach first, and move the code later, if the idea
of a multi-layered IR gets on.

Would that make sense in Clang? It should be a matter of code movement
more than new code, and would provide a common place for more
front-ends to use.

Duncan,

Would that make sense in dragonegg?

-- 
cheers,
--renato

http://systemcall.org/

Hi Renato,
> On 19 October 2012 16:40, Chandler Carruth <chandlerc at google.com>
wrote:
>> Don't get me wrong, I don't have any good ideas about how to do
this, I'm
>> just hoping someone does. End result might allow something like:
>>
>> declare void @foo(double inreg <eax,edx> %x)
>
> Hi Chandler,
>
> We were discussing about this on the Cambridge LLVM Social a while
> ago, and we felt that there were far too much target dependent stuff
> in the procedure call standards as it is.
>
> Our approach would be to have a PCS layer, either in the front-end or
> as a pass, that would know about both language and target to be able
> to construct calls as the target is expecting (ABI-wise).
>
> David Chisnall proposed a PCSBuilder (similar to IRBuilder, for
> building function calls), where you just pass the basic info (return
> type, arguments, flags, name) and it builds the function for you,
> mangling names, changing parameters and assigning things to registers
> when the ABI is less than helpful, possibly having an inreg syntax
> like you describe.
>
> My idea was to make it a pass, so you could delay the PCS mess up to a
> later stage, when possibly you'd already have more information about
> the target, but that's not necessarily true and might open the can of
> worms that is having a multi-layered IR. For simplicity, we might
> consider David's approach first, and move the code later, if the idea
> of a multi-layered IR gets on.
>
> Would that make sense in Clang? It should be a matter of code movement
> more than new code, and would provide a common place for more
> front-ends to use.
>
> Duncan,
>
> Would that make sense in dragonegg?
I was planning to go the other direction in dragonegg: be driven by GCC, which
tells you what to place on the stack, what to place in a register (and what
register to place it in).  That would fit much better with Chandler's
scheme.
That said, I also don't like the idea of filling the IR with tons of target
specific stuff.

Ciao, Duncan.

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.

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/