similar to: [LLVMdev] Addressing const reference in ArrayRef

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,

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

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

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,

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

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.

cB->getType()->getPointerElementType()->dump(); gives: %struct.RB = type opaque2189 x_idx = builder.CreateStructGEP(cB, 0); cB->dump() gives: %struct.RB addrspace(1)* %cB $1 = void //To undo confusion, the last cB is the function arg name. For this example I unfortunately chose the same name for my argument Value* as the argument name. //Also one correction. I am running

If I do M.dump(), at the top of the output I have: %struct.RB = type opaque Further down I have: @.str18 = internal addrspace(2) constant [13 x i8] c"RB_t*\00" However nowhere does it dump the full struct type when I call "M.dump()". I have it explicitly defined above the kernel in the kernel file, but LLVM doesn't seem to pick it up. Opaque is a placeholder until it

Sure, it is the Rodinia 2.4 Hotspot benchmark OpenCL kernel (not my kernel), with the addition of my struct as the last argument in the kernel function. //------- kernel file start ------------------------------- #define BLOCK_SIZE 16 //dlowell's type #define BUFFER_LEN 0x100000 typedef struct RB{ unsigned int x; unsigned int y; int z[BUFFER_LEN]; unsigned int xx[BUFFER_LEN];

Hi Team, I am migrating one of the Pass that was written for llvm2.2 or older to llvm3.1. The code snippet looks like the following: Constant *func; void add( Module *M) { func = M->getOrInsertFunction("func", Type::getVoidTy(M->getContext()), NULL); } virtual bool runOnModule(Module &M) { add (&M); for(Module::iterator F = M.begin(), E = M.end(); F !=

Hi Ahmad, On 03/01/13 16:26, Hassan, Ahmad wrote: > Hi Team, > > I am migrating one of the Pass that was written for llvm2.2 or older to llvm3.1. > The code snippet looks like the following: > > Constant *func; > > void add( Module *M) { > > func = M->getOrInsertFunction("func", Type::getVoidTy(M->getContext()), NULL); this function has no

Hi all, How can I create an llvm::GetElementPtrInst in which the pointer and the index are in registers previously loaded with llvm::LoadInst ? I mean, the generated instruction will be like this: %1 = getelementptr i8* %myreg1, i32 %myreg2 here, %myreg1 and %myreg2 are previously created by load instructions (llvm::LoadInst). Please, let me know if there is an example of something similar.

It is suggested in the documentation that if you would have declared a function parameter as SmallVector<Foo,N>&, it is better to instead declare it as SmallVectorImpl<Foo>&. This makes sense, but it seems to me that it is better still to declare it as ArrayRef<Foo>; a quick test suggests it compiles to the same (highly efficient) code, and adds a bit more flexibility in

It wraps a constant T* and a size_t, so I'm surprised std::sort works. It shouldn't. On Sep 30, 2017 5:22 PM, "Daniel Berlin via llvm-dev" < llvm-dev at lists.llvm.org> wrote: It seems like ArrayRefs are supposed to be immutable ( However, as far as i can tell, the iterators are defined wrong to make this true. While ArrayRef<int> Foo(Something); Foo[0] = 5; will

Hi all- I am mostly doing work in Clang (and am new there), so I apologize if this isn't the proper place to mention this. I appreciate guidance in advance. I was looking into some of the unit tests, and noticed that the ArrayRefTest.InitializerList, and thus the InitializerList constructor of ArrayRef (under normal use-case) hit undefined behavior. The test does the following:

+1, totally a bug. That’s the domain of MutableArrayRef. -Chris > On Oct 1, 2017, at 6:52 AM, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > +1 seems like a bug > > On Sun, Oct 1, 2017 at 12:35 AM Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > It wraps a constant T* and a size_t, so

ola, ive been looking at adding support for an -msave-args option for use on x86_64. the short explanation of it is that it makes x86_64 function prologues store their register arguments on the stack. the purpose of this is to make the arguments trivially accessible for things like stack traces with arguments. as per https://blogs.oracle.com/sherrym/entry/obtaining_function_arguments_on_amd64,

Sorry for the inline-comment format being weird, I haven't figured out yet how to do '>' stuff in outlook yet :/ Hopefully this is clear enough. -----Original Message----- From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] Sent: Wednesday, August 24, 2016 10:55 AM To: Keane, Erich <erich.keane at intel.com> Cc: llvm-dev at lists.llvm.org Subject: Re:

Hi, Why is StringRef not an ArrayRef<char> extension? That might simplify some interfaces. Cheers, Paweł -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151105/ef56dcdc/attachment.html>