similar to: [LLVMdev] Alignment on byval parameters

As you may have seen, my recent checkins complete implementing this for x86-32. It is possible some of it is not right for Linux, and I'd like to get some testing help. Probably the only thing you'd want to change is LLVM_BYVAL_ALIGNMENT in config/i386/llvm-i386-target.h; at the extreme, if you set that to 0 things should go back to the way they were. The best test I know for

I'm unable to figure out how IR attributes can be added via the C++ API. I need to create a function like this:     %1 = call i64 @abi_call_test_tuple_2p(%struct.abi_tuple_2p* byval align 8 %v) Where a structure is being passed by value. I need to add the `byval` attribute somewhere (I'm not clear if this is on the function arguments or the type). I'm also uncertain of why that

Hi Richard, > In that case if you did want the callee to copy the argument am I right > in thinking that the Frontend would have to pass a pointer and add an > explicit memcpy in the callee? I'm not sure what you are asking. Of course caller or callee can always allocate some temporary on the stack and memcpy to it, then use that copy from then on. The point of byval is that the

> I'm not sure what you are asking. Of course caller or callee can > always allocate some temporary on the stack and memcpy to it, then > use that copy from then on. The point of byval is that the copy is > made where the ABI mandates it for by-value call parameters. If > you don't need to be ABI compatible then there is no point using > byval: it would be better to

On gcc/x86, when a class or struct has a copy constructor or destructor and is passed by value to a function, the caller creates a temporary copy and passes a pointer to the copy. LLVM does the same. msvc++ does not use the pointer trick. It puts the class on the stack like any other function parameter. How to pass a class parameter `byval' while honoring the copy constructor and/or

Hi Arushi, > Thanks for the help. I tried this out, but on x86_64 and with llvm 2.6 > and llvm-gcc 4.2.1, I dont seem to get an aligned variable. does it work with llvm-2.7 (just released)? Ciao, Duncan.

I could not get the same .bc file work with llvm 2.7 on x86_64 either. This is the address I got for a byval argument meant to be aligned to 64byte boundary. 0x7fff3f0ae030 Any more pointers? Arushi PS: Is the IR representation in 2.7 any different, that I should not use the same bitcode file. On Tue, Apr 27, 2010 at 3:22 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Arushi,

Hi, I would like to try to fix LLVM bug 6965<http://llvm.org/bugs/show_bug.cgi?id=6965>, but I am new to the LLVM backend infrastructure. Any pointers on where to start exploring might be useful. Any hints on where such alignments are forced, or where the suspected problem might be will be useful. Thanks in advance Arushi -------------- next part -------------- An HTML attachment was

Duncan wrote: > Hi Alon, > > > The docs say "[byval] indicates that the pointer parameter should > > really be passed by value to the function. The attribute implies > > that a hidden copy of the pointee is made between the caller and > > the callee, so the callee is unable to modify the value in the > > callee." > > > > I am not sure what

Hi, For example consider code: typedef struct tag_instead_ll { int upper; int lower; int otherguys[9]; } instead_ll_t; __attribute__ ((noinline)) int foo (instead_ll_t value); int main(void) { instead_ll_t val; val.upper = 0x12345678; val.lower = 0x9abcdef; return foo(val); } On the entrance of my LowerCall function, IR looks like: *** IR Dump After Machine Function Analysis

An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130618/ee0ae442/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: 201306181842303_BEI0XT4N.gif Type: image/gif Size: 14036 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130618/ee0ae442/attachment.gif>

On 18 June 2013 14:12, Rajesh Viswabramana <rajesh.vis at samsung.com> wrote: > Yes, its soft-float, below is verbose of my command, > Thought so. Any reason to use ARMv4T triple? I don't think you're trying to install Linux on an ARM7TDMI, are you? ;) This look like the default if you just specify "arm" as your triple. We need to get that fixed to some sane value

An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130619/a2502bad/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: 201306191201558_BEI0XT4N.gif Type: image/gif Size: 14036 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130619/a2502bad/attachment.gif>

An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130620/9ee19538/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: 201306201804240_BEI0XT4N.gif Type: image/gif Size: 14036 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130620/9ee19538/attachment.gif>

On 20 June 2013 13:35, Rajesh Viswabramana <rajesh.vis at samsung.com> wrote: > - What considerations will be made from llvm side to make abi > compatibile with gcc/other compilers for arm - struct byval size >64 bytes. > Hi Rajesh, I'm not sure I follow your question, but in general, the idea is to be compatible with ABIs, not with specific compilers. So, if compiler X

An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130621/ac5e4be4/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: 201306211529044_QKNMBDIF.gif Type: image/gif Size: 14036 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130621/ac5e4be4/attachment.gif>

Hello guys, For single scalar pointer parameter, we have 'byval' to specify the pointee is not changed. But for base+range parameters like: declare void @_gfortran_transfer_integer_write(%struct.__st_parameter_dt*, i8*, i32) (This is the fortran runtime api to 'printf' one integer) The 2nd & 3rd args are used to specify the memory of that integer. I didn't find a

Hi Robert, > This should ideally be done early on in the IR in my thinking - to allow optimisation if the data is only ever read. I've thought that once or twice when dealing with ABIs myself. That's certainly another possibility in your case. You could create a separate FunctionPass that gets executed early on and replaces all byval calls and functions with the correct memcpys. It

Hi, Thanks for the help. I tried this out, but on x86_64 and with llvm 2.6 and llvm-gcc 4.2.1, I dont seem to get an aligned variable. This is the function definition that I have define internal fastcc void @walksub(%struct.hgstruct* noalias nocapture sret %agg.result, %struct.node* %p, double %dsq, %struct.hgstruct* byval align 64 %hg, i32 %level) nounwind { And these are the call sites,

Hi Arushi, > If I want a particular alignment on a ByVal argument, should I specify > it as a function attribute, or should I also add the attribute to > every callsite that calls that function. in theory you should do both. For example, if the call is an indirect call (i.e. to a function pointer where the function is not known) then it should be clear that you need to put the