search for: p0i64

Hello, I have a question, what is wrong with the following code? declare void @llvm.memcpy.p0i64.p0i64.i8(i64*, i64*, i8, i32, i1) nounwind ... call void @llvm.memcpy.p0i64.p0i64.i8(i64* %19, i64* %21, i8 %17, i32 0, i1 false) ... According to the compiler this is the error, but I seem to miss where exactly my fault is. Intrinsic prototype has incorrect number of arguments! void (i64*, i...

On Sep 7, 2010, at 8:03 AM, F van der Meeren wrote: > Hello, > > I have a question, what is wrong with the following code? > > declare void @llvm.memcpy.p0i64.p0i64.i8(i64*, i64*, i8, i32, i1) nounwind > > ... > > call void @llvm.memcpy.p0i64.p0i64.i8(i64* %19, i64* %21, i8 %17, i32 0, i1 false) > > ... > > > According to the compiler this is the error, but I seem to miss where exactly my fault is. > > Intrinsic pro...

On Sep 7, 2010, at 8:03 AM, F van der Meeren wrote: > Hello, > > I have a question, what is wrong with the following code? > > declare void @llvm.memcpy.p0i64.p0i64.i8(i64*, i64*, i8, i32, i1) nounwind > > ... > > call void @llvm.memcpy.p0i64.p0i64.i8(i64* %19, i64* %21, i8 %17, i32 0, i1 false) > > ... > > > According to the compiler this is the error, but I seem to miss where exactly my fault is. > > Intrinsic pro...

...stInt(LLVMInt32TypeInContext(context), 0, true), LLVMConstInt(LLVMInt1TypeInContext(context), (unsigned long long)false, true), }; LLVMBuildCall(builder, function, args, numberOfArguments, ""); Then you end up with the following prototype: declare void @llvm.memcpy.p0i64.p0i64.i64(i64*, i64*, i64, i32, i1) nounwind and this code will invoke the copy: reallocBlock: ; preds = %entry %5 = getelementptr inbounds %0* %0, i32 0, i32 2 ; <i64*> [#uses=1] %6 = load i64* %5 ; <i64> [#uses=1]...

declare i8 @llvm.atomic.load.max.i8.p0i8( i8* <ptr>, i8 <delta> ) declare i16 @llvm.atomic.load.max.i16.p0i16( i16* <ptr>, i16 <delta> ) declare i32 @llvm.atomic.load.max.i32.p0i32( i32* <ptr>, i32 <delta> ) declare i64 @llvm.atomic.load.max.i64.p0i64( i64* <ptr>, i64 <delta> ) declare i8 @llvm.atomic.load.min.i8.p0i8( i8* <ptr>, i8 <delta> ) declare i16 @llvm.atomic.load.min.i16.p0i16( i16* <ptr>, i16 <delta> ) declare i32 @llvm.atomic.load.min.i32..p0i32( i32* <ptr>, i32 <delta> ) declare...

...lare i8 @llvm.atomic.load.max.i8.p0i8( i8* <ptr>, i8 <delta> ) > declare i16 @llvm.atomic.load.max.i16.p0i16( i16* <ptr>, i16 <delta> ) > declare i32 @llvm.atomic.load.max.i32.p0i32( i32* <ptr>, i32 <delta> ) > declare i64 @llvm.atomic.load.max.i64.p0i64( i64* <ptr>, i64 <delta> ) > declare i8 @llvm.atomic.load.min.i8.p0i8( i8* <ptr>, i8 <delta> ) > declare i16 @llvm.atomic.load.min.i16.p0i16( i16* <ptr>, i16 <delta> ) > declare i32 @llvm.atomic.load.min.i32..p0i32( i32* <ptr>, i32 <delta&...

...hat inline asm would be the way to do so, but LLVM doesn't appear to support asm output when using the JIT compiler. Is there any hope for inline asm being supported with the JIT anytime soon? Or is there an alternative suggested way of doing this? I'm using llvm.atomic.load.sub.i64.p0i64 for the moment, but that's both more expensive than I need as it has an unnecessary LOCK prefix, and is also theoretically incorrect. While it generates correct code currently on x86-64, LLVM doesn't actually *guarantee* that it generates a single instruction, that's just "...

...be the way to > do so, but LLVM doesn't appear to support asm output when using the > JIT compiler. Is there any hope for inline asm being supported with > the JIT anytime soon? Or is there an alternative suggested way of > doing this? I'm using llvm.atomic.load.sub.i64.p0i64 for the moment, > but that's both more expensive than I need as it has an unnecessary > LOCK prefix, and is also theoretically incorrect. While it generates > correct code currently on x86-64, LLVM doesn't actually *guarantee* > that it generates a single instruction, th...

Responding to the original email... On Sun, Jan 3, 2010 at 10:10 PM, James Y Knight <foom at fuhm.net> wrote: > In working on an LLVM backend for SBCL (a lisp compiler), there are > certain sequences of code that must be atomic with regards to async > signals. Can you define exactly what 'atomic with regards to async signals' this entails? Your descriptions led me to think

...I needed before, and sorry if it confused you about what I'm trying to accomplish. Here's a concrete example, in hopes it will clarify matters: @pseudo_atomic = thread_local global i64 0 declare i64* @alloc(i64) declare void @do_pending_interrupt() declare i64 @llvm.atomic.load.sub.i64.p0i64(i64* nocapture, i64) nounwind declare void @llvm.memory.barrier(i1, i1, i1, i1, i1) define i64* @foo() { ;; Note that we're in an allocation section store i64 1, i64* @pseudo_atomic ;; Barrier only to ensure instruction ordering, not needed as a true memory barrier call void @l...

...way to >> do so, but LLVM doesn't appear to support asm output when using the >> JIT compiler. Is there any hope for inline asm being supported with >> the JIT anytime soon? Or is there an alternative suggested way of >> doing this? I'm using llvm.atomic.load.sub.i64.p0i64 for the moment, >> but that's both more expensive than I need as it has an unnecessary >> LOCK prefix, and is also theoretically incorrect. As I've mentioned above, I assure you the LOCK prefix matters. The strange thing is that you think this is inefficient. Modern processors...