similar to: byval argument causes llvm to crash after inlining

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>

This sounds right to me. If there is no objection, I will implement a patch to enforce this in langref and IR verifier. -----Original Message----- From: Friedman, Eli [mailto:efriedma at codeaurora.org] Sent: Tuesday, September 25, 2018 3:07 PM To: Pan, Wei <wei.pan at intel.com>; Reid Kleckner <rnk at google.com> Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: Re:

Hi Alexandre, Before the change you would have been expecting one of the following, correct? a) call void @llvm.memcpy.p3i8.p1i8.i64(i8 addrspace(3)* bitcast ([512 x float] addrspace(3)* [[SPM0]] to i8 addrspace(3)*), i8 addrspace(1)* [[APTR]], i64 2048, i32 0, i1 false) b) call void @llvm.memcpy.p3i8.p1i8.i64(i8 addrspace(3)* bitcast ([512 x float] addrspace(3)* [[SPM0]] to i8 addrspace(3)*), i8

Good question. AFAIK, the IR-printer doesn’t understand the semantics of parameter attributes. In this case, it only knows that there is an attribute on the parameter that is integer valued (with value 1) and that has the name “align”, so it prints it out. If we don’t want it printing out ‘align 1’ then it’s up to us to not set the alignment parameter attribute to a value if that value would be 1.

Yes, all that is correct. My question is more a long term question: why do the .ll printer specify the alignment if it is equivalent to the default one? That is, it seems the sed script expect the printer to not specify it (this would match the load/store behavior), but the ll-printer does specify it, which either means the printer is not ideal on this case and I should fix it, or in this case

Thanks, that worked like a charm except for the following: llvm generate: call void @llvm.memcpy.p3i8.p1i8.i64(i8 addrspace(3)* align 1 bitcast ([512 x float] addrspace(3)* @a_scratchpad to i8 addrspace(3)*), i8 addrspace(1)* align 1 %0, i64 2048, i1 false) And we expected: call void @llvm.memcpy.p3i8.p1i8.i64(i8 addrspace(3)* bitcast ([512 x float] addrspace(3)* [[SPM0]] to i8

> 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

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

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

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

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

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.

Duncan Sands wrote: > 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

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

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

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

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

Hi Tim, Correction to my last email. What I should have said is that the new pointer is used by the callee rather than the original byVal pointer arg. (the byVal pointer arg remains but is not used by the callee). viz: define void @f1(%struct.tag* byval) { entry: %st = alloca %struct.tag, align 4 %1 = bitcast %struct.tag* %st to i8* %2 = bitcast %struct.tag* %0 to i8* call void

Hello, I'm trying to change the default behavior for how structures are passed to functions to use pass-by-value. Currently LLVM's default behavior is to pass structures by reference. I'm not disputing the benefits of this but I really want to change the default behavior for experimentation purposes. To this end I've changed the code in DefaultABIInfo::classifyArgumentType() to

Reid is right that this would go in memcpyopt, but... we there's an active discussion on the commit list which will solve this through a different mechanism. There's an active desire to avoid teaching GVN and related pieces (of which memcpyopt is one) about first class aggregates. We don't have enough active users of the feature to justify and maintain the complexity. If you