search for: sret

...frame are included in the column names of the first data frame but if an element from the second object is not a column name of the first one, then it bugs. -More concretely, I have the following data frames d and v: yyyymmdd<-c("19720601", "19720602", "19720605") sret.10006<-c(1,2,3) sret.10014<-c(5,9,7) sret.10065<-c(10,2,11) d<- data.frame(yyyymmdd=yyyymmdd, sret.10006=sret.10006, sret.10014=sret.10014, sret.10065=sret.10065) v<- data.frame(V1="sret.10006", V2="sret.10090") v<- sapply(v, function(x) levels(x)[x]) -I wa...

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 sret is used for vectors. So my question is: should I, when updating the llvm-gcc, not set sret on my i128 shadow re...

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 objects too. LangRef doesn't > say scalars are allowed to have sret set, but sret is used for > vectors. > > So my question is: should I, when updating the llvm-gcc, not set...

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

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 different things here. What I am...

...ry to make these sorts of things "work". For example, if you pass parameters to a function pointer call and we later discover the function takes no parameters, instcombine will discard the arguments rather than making the call unreachable. IMO the same logic applies to ABI attributes like sret. 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. If you're doing an sret return, you need to return to the call address +12, instead of +8, because the instructi...

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 least 'sret' flag in call and declaration. ... call void @_Z7returnsi(%struct.MyString* %z, i32 %1) nounwind ... declare void @_Z7returnsi(%...

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? What is the exact meaning of "noalias sret"? Thank you all in advance. ---------...

..., 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 floats, which cannot be returned directly on an x86 using the traditional calling conventions but only via the sret mechanism. You might already have spotted that "readnone" attribute, which is causing s...

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 @llvm.lifetime.start.p0i8(i64 16, i8* nonnull %4) call void %1(%S* noalias nocapture nonnull sret dereferenceable(16) %3) %5 = bitcast %S* %0 to i8* call vo...

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 allocation; this transform > clones a fu...

...ich 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 alignstack(16) { ENTRY: %"@0" = alloca %vec3, align 4 call x86_thiscallcc void @vec3_Cross(%vec3* sret %"@0", %vec3* %v1, %vec3* %v2) ret void } declare x86_thiscallcc void @vec3_Cross(%vec3* sret, %vec3*, %vec3*) align 2 It seems that the code generated by the JIT takes the first parameter for the this value because of the X86_thiscall calling convention. However, in this particular c...

...rent ABI, >> and I don't think you can reasonably call it *just* "windows" at any point. >> >> This isn't quite true. Mingw and MSVC's ABIs on i386 also differ at the C > level—for instance, alignment of pass-by-value structs sometimes differs, > and an sret pointer is callee-cleanup in MSVC but caller-cleanup in Mingw. > There are other differences too. > Can you clarify what you mean by the "sret pointer is callee-cleanup" vs caller-cleanup? What we were specifically hitting yesterday was that MSVC expects the sret pointer passed in...

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 some JITed code produced by LLVM, and that code calls back into the host application occasionally. Since my language is purely functional, no functions have side-effects. Therefore I would like to be able to cache the value of identical...

The following has been done as a part of cleanup - o Eliminated bin_search() by replacing with btrfs_bin_search() o Eliminated unused return value in fixup_low_keys() o Eliminated additional variable (sret) in setup_nodes_for_search() Signed-off-by: Goldwyn Rodrigues <rgoldwyn@suse.de> --- ctree.c | 71 ++++++++++++++++++---------------------------------------------- 1 file changed, 20 insertions(+), 51 deletions(-) diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c index 9ac1715..69f71e8 10...

...ve 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. > > Does such situation make sense, or (as I guess it is) a bug in verifier? > I think verifier should match at least 'sret' flag in call and declaration. > > ... > call void @_Z7returnsi(%struct.MyString* %z, i32 %1) nounwind &...

...t; and I don't think you can reasonably call it *just* "windows" at any point. >>> >>> This isn't quite true. Mingw and MSVC's ABIs on i386 also differ at the >> C level—for instance, alignment of pass-by-value structs sometimes differs, >> and an sret pointer is callee-cleanup in MSVC but caller-cleanup in Mingw. >> There are other differences too. >> > > Can you clarify what you mean by the "sret pointer is callee-cleanup" vs > caller-cleanup? > In the epilog for a function with an indirect struct return argum...

...ould be a pointer to the return value: > > %vec3 = type <{ float, float, float }> > > define void @CPP_Return_Struct(%vec3* %v1, %vec3* %v2) inlinehint > alignstack(16) { > ENTRY: >  %"@0" = alloca %vec3, align 4 >  call x86_thiscallcc void @vec3_Cross(%vec3* sret %"@0", %vec3* %v1, %vec3* > %v2) >  ret void > } > > declare x86_thiscallcc void @vec3_Cross(%vec3* sret, %vec3*, %vec3*) align 2 > > It seems that the code generated by the JIT takes the first parameter for > the this value because of the X86_thiscall calling conv...

...vm-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 }* sret %tmp, double %conv, > > double 0.000000e+00, double %a.real, double %a.imag) #2 > > > > > > > > ... > > > > > > > > declare void @__muldc3({ double, double }*, double, double, double, > > double) > > > > > > > >...

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: it uses a fixed register to pass struct > return addresses, which is not used for ot...