similar to: [LLVMdev] Should the function operand flag 'sret' match the flag in function declaration?

On May 7, 2010, at 6:24 PM, Yuri wrote: > I have these two instructions, first one inside some procedure, second > one is an outside declaration. > Code verification passes and it runs, but incorrectly. Right, this code has undefined behavior. > Every time I saw such situation coming from c++ compiler, attributes > 'noalias sret' appear on both call and declaration.

On Sat, Oct 03, 2015 at 08:43:49AM -0700, Tim Northover wrote: > Hi Joerg, > > On 3 October 2015 at 02:29, Joerg Sonnenberger via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > while debugging assertions when building libm for 32bit Sparc, I hit the > > following IR: > > > > complex_mul_libcall: > > call void @__muldc3({ double, double }*

Hi, all When I compile the C code containing the next statement to LLVM, *struct A const o = func(...);* I got the next corresponding LLVM bytecode *call void @func(%struct.A* noalias sret %o, ...)* Could you tell me why function "func" with a return value is changed to be one with a void return value and another more parameter %o. Does "noalias sret" play a special role?

Hi all, I'm currently building a DSL for a computer graphics project that is not unlike NVIDIA's Cg. I have an intrinsic with the following signature float4 sample(texture tex, float2 coords); that is translated to this LLVM IR code: declare void @"sample"(%float4* noalias nocapture sret, %texture, $float2) nounwind readnone The type float4 is basically an array of four

On Oct 6, 2015, at 4:33 PM, Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Tue, Oct 6, 2015 at 1:21 PM, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Can you give an example of where it would trigger in LTO and when should > not? > > You could imagine that __muldc3 might be

On Wed, Oct 07, 2015 at 10:28:59AM +0200, Jonas Maebe via llvm-dev wrote: > > James Y Knight via llvm-dev wrote on Tue, 06 Oct 2015: > > >Certainly a mismatch between sret and not-sret from caller to callee could > >not possibly work on sparc, because sparc's calling convention for struct > >return is totally bonkers. > > It won't work on AArch64 either:

On Wed, Oct 07, 2015 at 04:35:10PM -0700, Tim Northover wrote: > > That seems to make it a pretty good case for consider sret mandatory in > > general. > > (Still) no more than any other type cast IMO. If you know what you're > doing you can cast function pointers (at the LLVM level), otherwise > you're going to get into trouble. I think we are talking about two

Hello, while debugging assertions when building libm for 32bit Sparc, I hit the following IR: complex_mul_libcall: call void @__muldc3({ double, double }* sret %tmp, double %conv, double 0.000000e+00, double %a.real, double %a.imag) #2 ... declare void @__muldc3({ double, double }*, double, double, double, double) The same IR is essentially generated for i386 too, so it is not Sparc

On Mon, Oct 05, 2015 at 03:45:29PM -0700, Reid Kleckner wrote: > > > On 3 October 2015 at 02:29, Joerg Sonnenberger via llvm-dev > > > <llvm-dev at lists.llvm.org> wrote: > > > > while debugging assertions when building libm for 32bit Sparc, I hit > > the > > > > following IR: > > > > > > > > complex_mul_libcall: >

Hi all, in Rust we have a bug report about about a missed optimization which one would expect CallSlot optimization to handle: https://github.com/rust-lang/rust/issues/48533 The IR looks like this: define void @bar(%S* noalias nocapture sret dereferenceable(16), void (%S*)* nocapture nonnull) unnamed_addr #0 { %3 = alloca %S, align 8 %4 = bitcast %S* %3 to i8* call void

I am needing to return i128 as a shadow return due to abi issues on alpha.  The problem I am running into is the code for doing that with scalars (currently only used for vectors, as far as I can tell) sets the sret on the parameter.  If I just go this path, then I am setting sret on an integer pointer, which verify objects too.  LangRef doesn't say scalars are allowed to have sret set, but

On 5 Okt., 23:33, Dan Gohman <goh... at apple.com> wrote: > > Is there a reason it needs to be an array? A vector of four floats > wouldn't have this problem, if that's an option. > Unfortunately that's not an option. At the moment I'm restricting myself to the use of scalar code only, in order to be able to vectorize the code easily later (e.g., float4 as it is

On Aug 19, 2010, at 1:38 PM, Andrew Lenharth wrote: > I am needing to return i128 as a shadow return due to abi issues on > alpha. The problem I am running into is the code for doing that with > scalars (currently only used for vectors, as far as I can tell) sets > the sret on the parameter. If I just go this path, then I am setting > sret on an integer pointer, which verify

It's been a while and I finally had the time to look into this. What I did was to build a custom AliasAnalysis pass, as Chris suggested, that returns AliasAnalysis::Mod for values passed to the sample function in the sret spot, and NoModRef for all other values. I'm also returning AliasAnalysis::AccessesArguments in the pass' getModRefBehavior methods. However, I haven't been

On Jun 2, 2008, at 11:11 PM, Tanya Lattner wrote: > Darwin/ppc: > SingleSource/Benchmarks/CoyoteBench/fftbench [ CBE ] > From what I can see comparing 2.3 with TOT, the "cexp" function is declared like this in 2.3: declare i128 @cexp({double, double}* byval) nounwind It used to be this: declare void @cexp({double, double}* noalias sret, {double, double}* byval)

Dear All, What is the purpose of the sret function parameter attribute? Does it affect the calling convention used during code generation, is it a hint to optimizations, or is it used for something else? I'm currently working on automatic pool allocation; this transform clones a function and adds extra parameters to the beginning of the function's parameter list. This means that I

On Wed, Jul 14, 2010 at 8:49 AM, John Criswell <criswell at uiuc.edu> wrote: > Dear All, > > What is the purpose of the sret function parameter attribute?  Does it > affect the calling convention used during code generation, is it a hint > to optimizations, or is it used for something else? Both of the above; see LangRef. > I'm currently working on automatic pool

Hi all, I am trying to generate LLVM IR that calls an external C++ function returning a structure by copy: vec3 vec3::Cross(const vec3& iV) const; Here is the LLVM IR that I am generating for win32 ABI, which says that the first parameter should be a pointer to the return value: %vec3 = type <{ float, float, float }> define void @CPP_Return_Struct(%vec3* %v1, %vec3* %v2) inlinehint

On Thu, Mar 28, 2013 at 8:55 AM, Reid Kleckner <rnk at google.com> wrote: > On Thu, Mar 28, 2013 at 8:22 AM, Joe Groff <arcata at gmail.com> wrote: > >> On Wed, Mar 27, 2013 at 8:15 PM, Chandler Carruth <chandlerc at google.com>wrote: >> >>> This is why I suggest that the Windows ABI is whatever MSVC happens to >>> do. The mingw ABI happens to

On Thu, Mar 28, 2013 at 8:22 AM, Joe Groff <arcata at gmail.com> wrote: > On Wed, Mar 27, 2013 at 8:15 PM, Chandler Carruth <chandlerc at google.com>wrote: > >> This is why I suggest that the Windows ABI is whatever MSVC happens to >> do. The mingw ABI happens to consist of a conjunction of what MSVC does for >> C and what GCC on Linux does for C++. That is a