search for: byvals

Hi, In the past months, several options have been presented for making byval (and similar attributes, such as inalloca or sret) work with opaque pointers. The main two I've seen were byval(T) and byval(N) where N is the size of T. They both have their upsides and downsides, for example: byval(T) would be a type-parametric attribute, which, AFAIK, does not already exist and may complicate

> 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

I have three modules: ----------------------------------------------------------------- s1.ll: %0 = type <{ i32, i32 }> define void @s1(%0* byval %myStruct) nounwind { return: ret void } ----------------------------------------------------------------- s2.ll: %0 = type <{ i32, i32 }> define void @s2(%0* byval %myStruct) nounwind { return: ret void }

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

On May 9, 2011, at 1:41 PM, Renato Golin wrote: [snip] > One example is the struct byval. The ARM back-end still doesn't > support struct byval (maybe now it does, I was away for a while), The ARM backend now supports struct byval for APCS. Extending it to support AAPCS shouldn't be too difficult. Alas, I won't have time to revisit this in the near future. stuart

Hi Xiaoyi, this looks like a bug to me - please file a bug report. Ciao, Duncan. On 01/11/12 04:35, Guo, Xiaoyi wrote: > I have three modules: > ----------------------------------------------------------------- > s1.ll: > > %0 = type <{ i32, i32 }> > > define void @s1(%0* byval %myStruct) nounwind { > return: > ret void > } >

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

On Wed, May 11, 2011 at 11:42 PM, Stuart Hastings <stuart at apple.com> wrote: > > On May 9, 2011, at 1:41 PM, Renato Golin wrote: > > [snip] > >> One example is the struct byval. The ARM back-end still doesn't >> support struct byval (maybe now it does, I was away for a while), > > The ARM backend now supports struct byval for APCS.  Extending it to

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>

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

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

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

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

...but just supporting the C++ API seems >> sufficient to me but I hadn't thought of that in my conversation with him) >> >> This does reflect part of the point of typeless pointers: that memory >> isn't typed, it's just bytes (and alignment). Globals, allocas, and byvals >> are all just that. >> >> Does any of this sound important/reasonable? >> >> >>> >>> >>>> I was going to agree - but poking around, it looks like we need >>>> alignment too, at least (not sure if we need other things beyond s...

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

On May 12, 2011, at 12:30 AM, Sandeep Patel wrote: > On Wed, May 11, 2011 at 11:42 PM, Stuart Hastings <stuart at apple.com> wrote: >> >> On May 9, 2011, at 1:41 PM, Renato Golin wrote: >> >> [snip] >> >>> One example is the struct byval. The ARM back-end still doesn't >>> support struct byval (maybe now it does, I was away for a

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?

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, I'm trying to make a function for using wine_get_unix_file_name in VB6 programs. Private Declare Function lstrcpyA Lib "kernel32.dll" (ByVal lpString1 As String, ByVal lpString2 As Long) As Long Public Declare Function GetProcessHeap Lib "kernel32" () As Long Public Declare Function HeapFree Lib "kernel32" (ByVal hHeap As Long, ByVal dwFlags As