similar to: SRET consistency between declaration and call site

Displaying 20 results from an estimated 6000 matches similar to: "SRET consistency between declaration and call site"

2015 Oct 03
2
SRET consistency between declaration and call site
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 }*
2015 Oct 06
3
SRET consistency between declaration and call site
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: >
2015 Oct 06
2
SRET consistency between declaration and call site
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
2015 Oct 08
2
SRET consistency between declaration and call site
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
2015 Oct 07
2
SRET consistency between declaration and call site
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:
2010 May 08
2
[LLVMdev] Should the function operand flag 'sret' match the flag in function declaration?
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
2010 May 08
0
[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.
2010 Aug 19
2
[LLVMdev] sret on scalars
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
2010 Aug 23
0
[LLVMdev] sret on scalars
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
2010 Jul 14
2
[LLVMdev] Question on sret
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
2018 Mar 05
1
Allow CallSlot optimization for throwing functions for sret arguments
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
2010 Jul 14
0
[LLVMdev] Question on sret
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
2015 Jul 16
2
[LLVMdev] What does "noalias sret" mean?
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?
2011 Aug 12
1
[LLVMdev] Using sret AND thiscall calling convention
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
2009 Oct 05
5
[LLVMdev] Functions: sret and readnone
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
2013 Mar 28
0
[LLVMdev] Fwd: [cfe-dev] Handling SRet on Windows x86
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
2013 Mar 28
2
[LLVMdev] Fwd: [cfe-dev] Handling SRet on Windows x86
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
2011 Aug 12
1
[LLVMdev] Using sret AND thiscall calling convention
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
2012 Oct 02
4
[LLVMdev] Handling SRet on Windows x86
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
2015 Mar 09
2
[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