search for: pr12193

...hoping someone does. End result might allow something like: > > declare void @foo(double inreg <eax,edx> %x) Not sure I would go all the way to specifying registers in the IL (although I liked it at some point). What I like most right now is something along the lines of http://llvm.org/pr12193. That makes it explicit if something is on the stack or in registers and that information is correct for both the caller and callee. What is left for codegen is counting the register arguments and computing stack offsets. Implementing that requires way more time than I have right now, but I think...

...t;>> >>> declare void @foo(double inreg <eax,edx> %x) >> >> Not sure I would go all the way to specifying registers in the IL >> (although I liked it at some point). What I like most right now is >> something along the lines of >> http://llvm.org/pr12193. That makes it explicit if something is on the >> stack or in registers and that information is correct for both the >> caller and callee. What is left for codegen is counting the register >> arguments and computing stack offsets. > > I'm 100% in favour of having &quot...

...tic, as there could be free registers available // when we need to pass this argument in memory, and LLVM could try to pass // the argument in the free register. This does not seem to happen currently, // but this code would be much safer if we could mark the argument with // 'onstack'. See PR12193. I am just wondering whether it is necessary to add onstack flag and is there any issue related to that? Another option, suggested by Daniel, is to convert HA to a convenient similar type the backend won't pass in registers. I tried to pass a struct with vector types, but the backend will exp...

...might allow something like: >> >> declare void @foo(double inreg <eax,edx> %x) > > Not sure I would go all the way to specifying registers in the IL > (although I liked it at some point). What I like most right now is > something along the lines of > http://llvm.org/pr12193. That makes it explicit if something is on the > stack or in registers and that information is correct for both the > caller and callee. What is left for codegen is counting the register > arguments and computing stack offsets. I'm 100% in favour of having "onstack" as a co...

>>> Not sure I would go all the way to specifying registers in the IL >>> (although I liked it at some point). What I like most right now is >>> something along the lines of >>> http://llvm.org/pr12193. That makes it explicit if something is on the >>> stack or in registers and that information is correct for both the >>> caller and callee. What is left for codegen is counting the register >>> arguments and computing stack offsets. >> >> I'm 100% in fav...

...ee registers available > // when we need to pass this argument in memory, and LLVM could try to pass > // the argument in the free register. This does not seem to happen > currently, > // but this code would be much safer if we could mark the argument with > // 'onstack'. See PR12193. > > I am just wondering whether it is necessary to add onstack flag and is there > any issue related to that? > > Another option, suggested by Daniel, is to convert HA to a convenient > similar type the backend won't pass in registers. > I tried to pass a struct with vecto...

...be free registers available > // when we need to pass this argument in memory, and LLVM could try to pass > // the argument in the free register. This does not seem to happen currently, > // but this code would be much safer if we could mark the argument with > // 'onstack'. See PR12193. > > I am just wondering whether it is necessary to add onstack flag and is there any issue related to that? > > Another option, suggested by Daniel, is to convert HA to a convenient similar type the backend won't pass in registers. > I tried to pass a struct with vector types,...

...s available >> // when we need to pass this argument in memory, and LLVM could try to pass >> // the argument in the free register. This does not seem to happen currently, >> // but this code would be much safer if we could mark the argument with >> // 'onstack'. See PR12193. >> >> I am just wondering whether it is necessary to add onstack flag and is there any issue related to that? >> >> Another option, suggested by Daniel, is to convert HA to a convenient similar type the backend won't pass in registers. >> I tried to pass a struc...

...>> // when we need to pass this argument in memory, and LLVM could try to pass >>> // the argument in the free register. This does not seem to happen currently, >>> // but this code would be much safer if we could mark the argument with >>> // 'onstack'. See PR12193. >>> >>> I am just wondering whether it is necessary to add onstack flag and is there any issue related to that? >>> >>> Another option, suggested by Daniel, is to convert HA to a convenient similar type the backend won't pass in registers. >>> I t...

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; };