similar to: [LLVMdev] A limitation of LLVM with regard to marking sret functions as readonly.

On 08/03/2015 18:07, Daniel Berlin wrote: > > > On Sun, Mar 8, 2015 at 9:55 AM, Nicholas Chapman > <admin at indigorenderer.com <mailto:admin at indigorenderer.com>> wrote: > > Hi all, > I have identified what seems to be a limitation of LLVM with > regard to marking 'sret functions' as pure/readonly. > > For some context - I have

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

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

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

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

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

I have these two instructions, first one inside some procedure, second one is an outside declaration. Code verification passes and it runs, but incorrectly. Every time I saw such situation coming from c++ compiler, attributes 'noalias sret' appear on both call and declaration. Does such situation make sense, or (as I guess it is) a bug in verifier? I think verifier should match at

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

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

On Fri, Aug 12, 2011 at 1:11 AM, Damien Gleizes <gleizesd at gmail.com> wrote: > > 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

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

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:

Hello Aaron, Anton, LLVM-dev, While working on http://llvm.org/PR13676#c6 I found out that whenever I compile code with class methods returning structures it get generated incompatible with MSVC. Looking at lib/Target/X86/X86CallingConv.td, I found out that CC_X86_32_ThisCall maps SRet to EAX but in fact it should push the address of the return temp on stack. The following patch fixes the issue

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