search for: onstacks

On Oct 20, 2012, at 12:58 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Rafael, > > On 19/10/12 18:27, Rafael Espíndola 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>

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 and there are sufficient consecutive VFP registers of the appropriate type unallocated then the argument is allocated to the lowest-numbered sequence of such registers. C.2.vfp If the argument is a VFP CPRC then any VFP registers that are unallocated are marked as

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

On Tue, 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 and there are sufficient consecutive > VFP registers of the appropriate type unallocated then the argument is > allocated to the lowest-numbered

In 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

Byval does not work for me, it will try to split the struct to fit into available core registers and the rest on stack. Sent from my iPhone On Oct 23, 2012, at 5:01 PM, Alex Rosenberg <alexr at leftfield.org> wrote: > In 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

Hi Rafael, On 19/10/12 18:27, Rafael Espíndola 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) > > Not sure I would go all the way to specifying registers in the IL > (although I liked it at

At the time, the ARM target didn't actually handle byval. Now it does. You should be able to get the old struct passing capability if you don't apply an attribute at all. Alex On Oct 23, 2012, at 10:00 PM, Manman Ren wrote: > > Byval does not work for me, it will try to split the struct to fit into available core registers and the rest on stack. > > Sent from my iPhone

> 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

On Sat, Oct 20, 2012 at 10:37 AM, Renato Golin <rengolin at systemcall.org> wrote: > 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

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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rsync wont synchronize some directories Hello, I'm trying to synchronize 2 servers. I set own module for each directory. Most of them do synchronize, but not the most important one with the 33Gb of date. I run truss in order to get the detailed output russ rsync -atlrpogHvv ilya@myip::public - - --password-file=/root/rsync_pass /home/public

Hi Tim, On 02/05/12 10:51, Tim Northover wrote: > 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

As many of you will know, handling of struct arguments in LLVM is actually slightly more fiddly than you might expect. For targets where aggregates are always passed on the stack it's easy enough, the Clang ABI code marks these arguments as byval and the call lowering code in LLVM will copy the object to the stack when needed. There are more options for when the target has more complex ABI

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

I am still unable to get the following command to work correctly. The x's replace the correct entry obviously. smbclient -Lboss -Uxxxxxx%xxxxxxxx I decided to run the command as root preceeded by 'truss' so I could generate a debug output. This is the output from the command without 'truss' Domain=[BOSS] OS=[Windows 5.1] Server=[Windows 2000 LAN Manager] Sharename