similar to: [LLVMdev] LLI Segfaulting

Hi Duncan, Duncan Sands wrote: > > Hi Fraser, it looks to me like you are smashing the stack. > >> define void @main() nounwind { >> allocas: >> %0 = alloca { i32, [0 x i32] }, align 8 > > ^ this allocates 4 bytes on the stack. > >> %2 = getelementptr inbounds { i32, [0 x i32] }* %0, i64 0, i32 1 > > ^ this gets a pointer to the byte

Hi Fraser, Is there anything preventing you from using a pointer for the second part of the structure and allocating memory for it later? Thanks, Gavin On Mar 12, 2012, at 10:35 AM, Fraser Cormack wrote: > > Hi Duncan, > > > Duncan Sands wrote: >> >> Hi Fraser, it looks to me like you are smashing the stack. >> >>> define void @main() nounwind {

Hi Gavin, Do you mean something along the lines of having my array struct as { i32, i32* } and then indexing it with a gep and allocating the appropriate memory when I learn of it? Thanks, Fraser Gavin Harrison-2 wrote: > > Hi Fraser, > > Is there anything preventing you from using a pointer for the second part > of the structure and allocating memory for it later? > >

Yes, that is what I mean. :-) On Mar 12, 2012 11:02 AM, "Fraser Cormack" <frasercrmck at gmail.com> wrote: > > Hi Gavin, > > Do you mean something along the lines of having my array struct as { i32, > i32* } and then indexing it with a gep and allocating the appropriate > memory > when I learn of it? > > Thanks, > Fraser > > > Gavin

Sorry for my ignorance, but I'm unaware as to how I'd achieve this. I know I'd have this, %MainClass = type { { i32, i32* } } And something along these lines: %1 = getelementptr inbounds %MainClass* %0, i32 0, i32 0 ; get to the 'array' %2 = getelementptr inbounds { i32, i32* }* %1, i32 0, i32 1 ; index the data pointer And then I'd want to: alloca i32, i64 5

Hi Fraser, it looks to me like you are smashing the stack. > define void @main() nounwind { > allocas: > %0 = alloca { i32, [0 x i32] }, align 8 ^ this allocates 4 bytes on the stack. > %2 = getelementptr inbounds { i32, [0 x i32] }* %0, i64 0, i32 1 ^ this gets a pointer to the byte after the 4 allocated bytes. > %3 = bitcast [0 x i32]* %2 to i8* > call void

Eli Friedman-2 wrote: > > > Try llvm::Constant::getNullValue(). > > Thanks, that's working nicely (so far). Eli Friedman-2 wrote: > > > Yes; [0 x i32] isn't really a variable-length array, just a > placeholder for an array of unknown size. You have to track the size > yourself. > > This is working, too, however I'm getting a segmentation

Hi Does anybody use *StartJnjvmWithJIT* from jvjvm.cpp in VMKit? Becuase , I am looking to use without JIT when we are running the Java byte code. My concern is StartJnjvmWithJIT getting three argument *int argc, char** argv, char* mainClass* - why we need to pass *argv and mainclass* arguments here? please help me on this. Regards Sri. -------------- next part -------------- An

On Wed, Feb 22, 2012 at 1:56 PM, Fraser Cormack <frasercrmck at gmail.com> wrote: > > I'm trying to work out the size of a struct so that I can pass this to the > 'llvm.memcpy' intrinsic. It's easy to find out how I'm supposed to do this, > as I keep seeing the following: > > %Size = getelementptr %T* null, int 1 > %SizeI = cast %T* %Size to uint >

I'm trying to work out the size of a struct so that I can pass this to the 'llvm.memcpy' intrinsic. It's easy to find out how I'm supposed to do this, as I keep seeing the following: %Size = getelementptr %T* null, int 1 %SizeI = cast %T* %Size to uint But I'm unsure how I actually do this in the C++ API. Is the 'null' here a llvm::ConstantPointerNull? Any help

Hi all, Consider the following example: define void @fn(i8* %buf) #0 { entry: %arrayidx = getelementptr i8* %buf, i64 18 tail call void @llvm.memcpy.p0i8.p0i8.i64(i8* %arrayidx, i8* %buf, i64 18, i32 1, i1 false) %arrayidx1 = getelementptr i8* %buf, i64 18 store i8 1, i8* %arrayidx1, align 1 tail call void @llvm.memcpy.p0i8.p0i8.i64(i8* %buf, i8* %arrayidx, i64 18, i32 1, i1 false)

Hello, What intrinsics "@llvm.lifetime.start/@llvm.lifetime.end" really do? As per my knowledge, they define the live ranges of variables. In the following code section, they seem redundant. However, when I remove them, the behavior of the code becomes non-deterministic. The live ranges of the variables defined by them are never used in the code. Thanks, --------------- %37 = bitcast

Hi All, I came across a FileCheck failure I don't understand why. The example code below: void test1() { ... code ... // CHECK-LABEL: @test1 // CHECK: void @llvm.memcpy.p0i8.p0i8.i32 - (1) } void dummy() { // make (1) match ... code ... // CHECK-LABEL: @dummy } void test2() { ... code ... // CHECK-LABEL: @test2 //

The front end I'm building for an existing interpreted language is unfortunately producing output similar to this far too often; define void @foo(i8* nocapture %dest, i8* nocapture %src, i32 %len) nounwind { %1 = tail call noalias i8* @malloc(i32 %len) nounwind tail call void @llvm.memcpy.p0i8.p0i8.i32(i8* %1, i8* %src, i32 %len, i32 1, i1 false) tail call void

> could you allocate the memory on the stack instead (alloca instruction)? This is mainly for string or binary blob handling, using the stack isn't a great idea for size reasons. While I'm experimenting with simple code examples now, and I picked a simple one for this email. I'm certain things will get much more complicated once I implement more features of the language. On Tue,

On Jan 18, 2018, at 10:48 PM, Chris Lattner <clattner at nondot.org<mailto:clattner at nondot.org>> wrote: On Jan 18, 2018, at 7:45 AM, Daniel Neilson via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hi all, This change has been reviewed, and appears to be ready to land (review available here if anyone still wants to chime in:

The new @llvm.memcpy API does not have an alignment parameter. Instead the docs say to use the align <n> attribute. How is this supposed to work with different alignments? For example, I have one memcpy with align 4, align 4, and another with align 1, align 1. ; Function Attrs: argmemonly nounwind declare void @llvm.memcpy.p0i8.p0i8.i64(i8* nocapture writeonly align 4, i8* nocapture

The frontend code is a pretty simple for loop, that counts from i = 0; i != 10; i += 1 It gets optimized into and endless loop. export fn entry() void { var array: [10]Bar = undefined; var x = for (array) |elem, i| { if (i == 1) break elem; } else bar2(); } Here's the generated IR: ; ModuleID = 'test' source_filename = "test" target datalayout =

On 3/22/2018 3:15 PM, Andrew Kelley via llvm-dev wrote: > The new @llvm.memcpy API does not have an alignment parameter. Instead > the docs say to use the align <n> attribute. How is this supposed to > work with different alignments? > > For example, I have one memcpy with align 4, align 4, and another with > align 1, align 1. > > ; Function Attrs: argmemonly

Consider the following IR example: define void @simple([4 x double] *%ptr, i64 %idx) { %stack = alloca [4 x double] %ptri8 = bitcast [4 x double] *%ptr to i8* %stacki8 = bitcast [4 x double] *%stack to i8* call void @llvm.memcpy.p0i8.p0i8.i32(i8 *%stacki8, i8 *%ptri8, i32 32, i32 0, i1 0) %dataptr = getelementptr inbounds [4 x double], [4 x double] *%ptr, i32 0, i64 %idx