search for: pcsbuilder

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

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

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

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

Personally, I'd love to see a setup where instead of LLVM implementing each calling convention and ABI hack, we provide a means of actually describing this. Specifically, I'd love to see a design for how to specify in the IR which register(s) (if any register(s)) a particular value should be placed into. Don't get me wrong, I don't have any good ideas about how to do this, I'm

Functions with __attribute__((fastcall)) pop their arguments and take up to two arguments in ecx and edx. Currently we represent them by just setting the x86_fastcallcc calling convention. The problem is that the ABI has some strange conventions on when a register is used or not. For example: void __attribute__((fastcall)) foo1(int y); will take 'y' in ecx, but struct S1 { int x; };