search for: llvmbuildextractvalu

...ot sure about these functions. There really isn't any other way > to get to the value of any other constant, so why do you need this? When I've parsed an int literal and put it on my evaluation stack as a Value, there's a case where I need to get it back as an int. Specifically, the LLVMBuildExtractValue function requires an int, not a Constant, to represent the member. I believe that GEP does as well when applied to a struct. > > >  /* Operations on composite constants */ > @@ -464,6 +479,7 @@ >  LLVMValueRef LLVMConstVector(LLVMValueRef *ScalarConstantVals, unsigned Size); >...

...value into a register, therefore you must already have the address already. Or am I misinterpreting what you're saying? > When I've parsed an int literal and put it on my evaluation stack as a > Value, there's a case where I need to get it back as an int. > Specifically, the LLVMBuildExtractValue function requires an int, not > a Constant, to represent the member.  I believe that GEP does as well > when applied to a struct. GEP doesn't need to take a constant to work. %0 = alloca { i32, i32 } %1 = alloca i32 store i32 0, %1 %2 = load %1 %3 = getelementptr { i32, i32 }*, i32 0,...

On Tue, Oct 6, 2009 at 5:47 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > On Tue, Oct 6, 2009 at 2:13 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > > LLVMGetAttribute had a bug in it.  Here's the revised version of the patch Hi Kenneth! I wouldn't say that I'm the best reviewer, but I've been doing some work with the c bindings recently so