search for: onstack

...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 complement to "inreg". I'm > not so happy about the more funky changes you suggested in the PR, namely > having the callee no longer match the caller, but "onstack" itself makes > a lot of sense to me. Makes a lot of sense to me too. -Chris

...umption is optimistic, 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 th...

...icit 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 complement to "inreg". I'm >> not so happy about the more funky changes you suggested in the PR, namely >> having the callee no longer match the caller, but "onstack" itself makes >> a lot of sense to me. > > Makes a lot of sense to me too...

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

...n llvm-gcc, this decision was handled near llvm-arm.cpp:2737 in llvm_arm_aggregate_partially_passed_in_regs(). Basically, available registers would be counted up and if the HA didn't fit, it went byval instead. I agree that we should unify this sort of logic in one place. I'm not sure that onstack is the best interim step toward that. Does byval work here? Alex On Oct 23, 2012, at 11:22 AM, manman ren <mren at apple.com> wrote: > > Hi All, > > I am trying to handle the Homogeneous Aggregate for ARM-VFP according to the spec: > C.1.vfp If the argument is a VFP CPRC a...

..., this decision was handled near llvm-arm.cpp:2737 in llvm_arm_aggregate_partially_passed_in_regs(). Basically, available registers would be counted up and if the HA didn't fit, it went byval instead. > > I agree that we should unify this sort of logic in one place. I'm not sure that onstack is the best interim step toward that. Does byval work here? > > Alex > > On Oct 23, 2012, at 11:22 AM, manman ren <mren at apple.com> wrote: > >> >> Hi All, >> >> I am trying to handle the Homogeneous Aggregate for ARM-VFP according to the spec: &gt...

...tp://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 complement to "inreg". I'm not so happy about the more funky changes you suggested in the PR, namely having the callee no longer match the caller, but "onstack" itself makes a lot of sense to me. > Implementing that requires way more time than I have right no...

...ecision was handled near llvm-arm.cpp:2737 in llvm_arm_aggregate_partially_passed_in_regs(). Basically, available registers would be counted up and if the HA didn't fit, it went byval instead. >> >> I agree that we should unify this sort of logic in one place. I'm not sure that onstack is the best interim step toward that. Does byval work here? >> >> Alex >> >> On Oct 23, 2012, at 11:22 AM, manman ren <mren at apple.com> wrote: >> >>> >>> Hi All, >>> >>> I am trying to handle the Homogeneous Aggregate fo...

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

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

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

...ite(3,0xc20000,4092) ERR#1 'Operation not permitted' rsync: writefd_unbuffered failed to write 4092 bytes [generator]: Operation not permitted (1)write(2,0x7fffffffa4f0,93) = 93 (0x5d) write(2,0x80083ce67,1) = 1 (0x1) sigaction(SIGUSR1,{ SIG_IGN 0x0|ONSTACK|RESTART|RESETHAND|NOCLDSTOP|NODEFER|NOCLDWAIT|SIGINFO ss_t },0x0) = 0 (0x0) sigaction(SIGUSR2,{ SIG_IGN 0x0|ONSTACK|RESTART|RESETHAND|NOCLDSTOP|NODEFER|NOCLDWAIT|SIGINFO ss_t },0x0) = 0 (0x0) getpid() = 42660 (0xa6a4) kill(0xa6a5,0x1e) = 0 (0x0...

...tion in which the struct is not addressable (just like a virtual register) and just needs to have bits of it passed on the stack because the ABI says so (also like virtual registers: the first ones are passed in registers, the rest on the stack). To make this easier, maybe there should be an "onstack" parameter attribute (kind of the opposite to "inreg"), which says that an argument should be passed on the stack. Then you can break your struct up into bits that should be passed in registers ("inreg" attribute), bits that should be passed transparently (i.e. not address...

...t;, but not others. There's been some discussion of this issue previously: * In the context of PowerPC, which will coerce structs below a certain size to an integer array <http://lists.llvm.org/pipermail/llvm-dev/2015-March/083554.html> * Previous suggestions that we really want an "onstack" attribute <http://lists.llvm.org/pipermail/llvm-dev/2012-May/049406.html> I'm working with a calling convention (https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md) where structs of up to two words in length should be passed in registers, but otherwise on the sta...

On Wednesday 02 May 2012 09:12:16 Duncan Sands wrote: > > As I can understand, LLVM is trying to decompose datatypes into smaller > > components in some circumstances. > > Can you please explain more what you are referring to here. LLVM itself > shouldn't be changing function parameters or return types unless the > function has local (internal) linkage (since in that

...(0x0) mmap(0x0,27000,(0x3)PROT_READ|PROT_WRITE,(0x1000)MAP_ANON,-1,0x0) = 677171200 (0x285cd000) munmap(0x285cd000,0x6978) = 0 (0x0) mmap(0x0,5552,(0x3)PROT_READ|PROT_WRITE,(0x1000)MAP_ANON,-1,0x0) = 677171200 (0x285cd000) munmap(0x285cd000,0x15b0) = 0 (0x0) sigaction(SIGILL,{ 0x2812f460 0x0|ONSTACK|RESTART|RESETHAND|NOCLDSTOP|NODEFER|NOCLDWAIT|SIGINFO ss_t },{ SIG_DFL 0x0|ONSTACK|RESTART|RESETHAND|NOCLDSTOP|NODEFER|NOCLDWAIT|SIGINFO ss_t }) = 0 (0x0) sigprocmask(0x1,0x0,0x281488fc) = 0 (0x0) sigaction(SIGILL,{ SIG_DFL 0x0|ONSTACK|RESTART|RESETHAND|NOCLDSTOP|NODEFER|NOCLDWAIT|SIGINFO ss_t }...