similar to: [LLVMdev] Setting alignment for a ByVal argument

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

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

LLVM developers, I was wondering if the program would still be safe if I strip the byval attributes from the parameters in the entire bitcode. LLVM language reference manual states that "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. This attribute is only valid on LLVM pointer

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

Hello all, I'm trying to find the pass that would convert from: define void @main(%struct* byval %ptr) { %val = load %struct* %ptr %val.ptr = alloca %struct store %struct %val, %struct* %val.ptr call void @extern_func(%struct* byval %val.ptr) ret void } to this: define void @main(%struct* byval %ptr) { call void @extern_func(%struct* byval %ptr) ret void } First, am I missing

Hello, With the following reduced test case, cmd "opt -always-inline t.ll" crashes after inlining. Notice that byval argument %a will be remapped to %1 below, and consequently produces an illegal store. %1 = alloca i32, align 4 store i32 * %1, i32 addrspace(1)** %a.addr, align 8 Looks like Inliner assumes that byval arguments are from address space 0. Or this is just a bug in inliner?

2016-01-20 1:11 GMT+02:00 Antoine Pitrou via llvm-dev < llvm-dev at lists.llvm.org>: > On Wed, 20 Jan 2016 00:47:56 +0200 > "Eddy B. via llvm-dev" <llvm-dev at lists.llvm.org> wrote: > > > > I would love to know your thoughts on this, and more specifically: > > Which of the 3 (byval(T), byval(N) and byval + dereferenceable + align) > > do you

It is problematic when byval argument is not from address space 0. When the default alloca address space is 0, should we consider this IR illegal? define internal i32 @bar(i32 addrspace(1)* byval %a) alwaysinline From: Reid Kleckner [mailto:rnk at google.com] Sent: Tuesday, September 25, 2018 2:38 PM To: Pan, Wei <wei.pan at intel.com> Cc: llvm-dev <llvm-dev at lists.llvm.org>

Hi Tim, I may be missing something but using CCPassByVal is moving the pointer onto the stack - not what I'm after. I need to add an operation to the function prolog that actually makes a copy of the pointed to data. It is the responsibility of the callee to make the copy, not the caller - hence my trouble. (currently the callee can corrupt the original data viz pass-by-reference!) This

On Mon, Mar 9, 2015 at 12:38 PM, Reid Kleckner <rnk at google.com> wrote: > If we're keeping types on GEP, > You mean rather than just dropping gep entirely & doing manual pointer arithmetic? (& moving inbounds to an attribute on pointer addition, I guess?) > then IMO we should keep them on allocas and globals. It keeps the IR human > readable. > & what of

Hello, I am seeking a clarification of the semantics of 'byval' parameter attribute in llvm IR. Let's assume the ABI says the caller should create the 'hidden copy' of the pointee. My question is which part of the compiler chain should generate the alloca and copy code. My understanding is that it is the target code generator, not the provider of the llvm IR. But given the

Hi Robert, suppose you have a "byval" argument with type T*, and the caller passes a T* called %X for it, while in the callee the argument is called %Y. The IR level semantics are: (1) a copy should be made of *%X. Whether the callee or the caller makes the copy depends on the platform ABI. (2) in the callee, %Y refers to the address of this copy. There are many ways (1) can be

Hi, byval means that the parameter setup code for performing a call copies the struct onto the stack, in an appropriate position relative to the other call parameters. > I'm particularly confused by the "between the caller and the callee" part. The > way I see this, the responsibility for the copying should be with either the > caller or the callee, It is with the caller.

Hi, after working with llvm for a while, I'm still a little confused with the meaning of the 'byval' attribute. From the langref: "This 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.

> Do all tests need it? Align is just for non-default alignment (> align(1)) so it may be OK for the tests to omit it & it's probably not right to /require/ an align attribute on a byval parameter. I've had to fix some of the tests which checked that the right alignment was applied, by looking at the generated asm, but had no "align A" attributes and relied on the

Hi Tim, Thought about it last night and was coming to the same conclusion. 1. it cant be done at the end during lowering (target backend). 2. it should be part of llvm as the byVal needs to be handled. As a twist, I have been told that llvm-gcc can lower byVal into memcpy in the callee. I may take a look at this. I wonder if it ever emits 'byVal'... I still feel I don't understand