similar to: [LLVMdev] GetElementPtrInst question

Hi, You'd use an IRBuilder, like you did to create your LoadInsts. IRBuilder<> IRB(BB); IRB.CreateGEP(myreg1, myreg2); I assume because you asked this question, something went wrong when using the above method. What was it? :) Cheers, James ________________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eduardo [erocha.ssa

Hi James, Thanks for your quick reply. > I assume because you asked this question, something went wrong when using the above method. What was it? :) No, I am not using this method. I was trying to create a llvm::GetElementPtrInst . I didn't create IRBuilder. I am writing a ModulePass that insert new instruction to an existing Module. Besides, how can you get a reference to myreg1 ?

Hi, I'm having a hard time finding an answer to what I assume is a very basic idea. I'm trying to produce this llvm code using the LLVM api: %myString = alloca [13 x i8], i32 13 store [13 x i8] c"Hello world.\00", [13 x i8]* %myString %tmp1 = getelementptr [13 x i8]* %myString, i32 0, i32 0 %tmp2 = call i32 (i8*, ...)* @printf( i8* %tmp1 ) nounwind A simple Hello

The GEP constructor does not assert that the source and destination types match. Of course, this is incorrect and causes random failures somewhere down the line. Could I add general sanity checks to the GEP constructor? In general, is an Instruction allowed to be in an inconsistent state? If so, is there some well known method to "verify" whether an instruction is consistent or not?

Hi everyone. I'm trying to use the segmented function with the following data: For instance, I use segmented package as follow: myreg2 = lm(xy$y ~ xy$x) mysegmented = segmented(myreg2, seg.Z=~x, psi=c(245000), control = seg.control(display=FALSE)) Which get me to the following error : As a break point, a starting guess of 245000 seems fair. Anyone has an idea why I'm getting such

If I dump the Value of GetElementPtrInst->getPointerOperand(), I got this: %a = alloca [10 x i32], align 16 Obviously, there should be a way to get the dimension and element type via the "Value" returned from GetElementPtrInst->getPointerOperand(), but how? What kind of "Value" is this? Thanks! Welson -------------- next part -------------- An HTML attachment was

Hi During a pass, the XCore target lowers thread local global variables by turning them into global variable arrays indexed by the (max 8) thread ID. (see XCoreLowerThreadLocal.cpp) This works fine for instructions e.g. GetElementPtrInst But can't be done for constants e.g. GetElementPtrConstantExpr Thus I would like to replace GetElementPtrConstantExpr with GetElementPtrInst when it is

Hi Pankaj, your best bet is to send the entire bitcode before and after instcombine runs. Ciao, Duncan.

Analyzing why GCC failed to build LLVM recently, one root cause lies in definition of ArrayRef: // ArrayRef.h: ArrayRef(const T &OneElt) : Data(&OneElt), Length(1) {} Here address of const reference is taken and stored to an object. It is believed that live range of const reference is only at the function call site, escaping of its address to an object with a longer live range is invalid.

Hi Pankaj, are you testing this on valid bitcode? The bitcode you sent me did not pass the verifier, i.e. was not valid. Optimizers can be expected to do strange and wrong things if passed invalid bitcode. That is not a bug in LLVM: it is user error if a user doesn't use valid bitcode. Ciao, Duncan. > I think, finally, I want to conclude on this. > The problem I see is that if I

Hi All,   I have been having this issue, when I am enable Instruction Combining pass, for an application. I have read similar post ealier, http://old.nabble.com/Instruction-Combining-Pass-*Breaking*-Struct-Reads--td24253572.html With reference to the above case, my target data layout is defined as: DataLayout("e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-a:32:32") Thus I don't see

With reference to the previous query, I think, i miscalculated the offset, just recalculating. 1. without instruction combining coupling member variable, is at:   %struct._FRAME_DATA* %2, i32 0, i32 5   where "%2" is defined as:   %arrayidx3 = getelementptr inbounds i16* %Data, i32 1024, !dbg !446   %2 = bitcast i16* %arrayidx3 to %struct._FRAME_DATA*, !dbg !446 i.e. at 5 offset in

Hi, I think I ran into a rather subtle bug inside llvm/ADT/ArrayRef.h which only shows up when compiling the code with GCC-4.8 with switched-off optimizations. (Both clang and GCC-4.7 don't trigger the bug.) I already filed a bug against GCC-4.8 which was rejected by the GCC-folks as being invalid, because the code (basically ArrayRef.h) "is doing something bad - it's retaining a

On Fri, Aug 22, 2014 at 11:22 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > >> On 2014-Aug-22, at 10:43, David Blaikie <dblaikie at gmail.com> wrote: >> >> Yep - the convenience of one-element->ArrayRef is "cute" at best, I >> think. Having to wrap it doesn't seem detrimental. Would have to look >> at some numbers,

I think, finally, I want to conclude on this.   The problem I see is that if I comment the case for "simplificaiton of bitcast to gep of original struct in instruction combining", wherein there is a case for if the offset by which GEP moves the pointer is non-zero.   If I disable this code, then structure elements size, I get is

David Blaikie <dblaikie at gmail.com> writes: > I seem to recall discussing this before - is there an existing llvm > bug filed, another email thread or something (or perhaps it was just > an IRC conversation)? It would be good to keep all the discussion > together or at least reference the prior (llvm community) discussion. I'm not sure if it's been discussed before,

On Fri, Aug 22, 2014 at 10:16 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: >> On 2014-Aug-21, at 10:39, David Blaikie <dblaikie at gmail.com> wrote: >> >> On Thu, Aug 21, 2014 at 10:34 AM, Reid Kleckner <rnk at google.com> wrote: >>> Is there some way we can get lifetime extension of temporaries to kick in >>> here? >>

Yeah - I suspect there are just too many cases where we use this ctor correctly: where the ArrayRef is only a temporary to a function call. Perhaps this is a problem for which the best solution is a clang-tidy checker - though I'm not sure if we have good integration there yet. (& yes, Andreas, that looks like the previous thread - thanks!) On Thu, Aug 21, 2014 at 5:09 AM, Andreas Weber

On Thu, Aug 21, 2014 at 10:34 AM, Reid Kleckner <rnk at google.com> wrote: > Is there some way we can get lifetime extension of temporaries to kick in > here? Nope - since the temporary is a subexpression - not the thing being declared. > > > On Thu, Aug 21, 2014 at 8:05 AM, David Blaikie <dblaikie at gmail.com> wrote: >> >> Yeah - I suspect there are just

Hi all, Running LLVM 3.4 to create a custom pass for OpenCL transformations. I am attempting to GEP into a struct using IRBuilder's CreateStructGEP, but I keep getting this assert: aoc: ../../../../../../compiler/llvm/include/llvm/Instructions.h:703: llvm::Type* llvm::checkGEPType(llvm::Type*): Assertion `Ty && "Invalid GetElementPtrInst indices for type!"' failed.