similar to: [LLVMdev] Overlapping Allocas

On 12/2/11 3:24 PM, Eli Friedman wrote: > On Fri, Dec 2, 2011 at 1:04 PM, John Criswell<criswell at illinois.edu> wrote: >> Dear All, >> >> Is there an optimization in the x86 back-end that could cause two >> alloca's to use overlapping memory? > It's theoretically possible, but IIRC there isn't any such > optimization implemented at the moment.

On 12/2/11 4:27 PM, Eli Friedman wrote: > On Fri, Dec 2, 2011 at 2:23 PM, John Criswell<criswell at illinois.edu> wrote: >> On 12/2/11 3:24 PM, Eli Friedman wrote: >>> On Fri, Dec 2, 2011 at 1:04 PM, John Criswell<criswell at illinois.edu> >>> wrote: >>>> Dear All, >>>> >>>> Is there an optimization in the x86 back-end

On Fri, Dec 2, 2011 at 2:23 PM, John Criswell <criswell at illinois.edu> wrote: > On 12/2/11 3:24 PM, Eli Friedman wrote: >> >> On Fri, Dec 2, 2011 at 1:04 PM, John Criswell<criswell at illinois.edu> >>  wrote: >>> >>> Dear All, >>> >>> Is there an optimization in the x86 back-end that could cause two >>> alloca's to

On Fri, Dec 2, 2011 at 1:04 PM, John Criswell <criswell at illinois.edu> wrote: > Dear All, > > Is there an optimization in the x86 back-end that could cause two > alloca's to use overlapping memory? It's theoretically possible, but IIRC there isn't any such optimization implemented at the moment. -Eli

On 3/11/13 6:32 AM, Mikael Lepistö wrote: > Hi, > > I'm doing llvm pass for OpenCL code which does some memory checking to > verify that code does not access memory outside of the programs own > statically allocated areas. If you're looking to see if your program only accesses in-bounds memory, SAFECode and Address Sanitizer may be able to do this for you already. If

Hi, I'm doing llvm pass for OpenCL code which does some memory checking to verify that code does not access memory outside of the programs own statically allocated areas. To make dynamic check generation easier, I would like to collect all allocas and global variable definitions and create one big memory structure (for each global, local and private) containing all the allocated memory as

The Kaleidoscope example here: http://llvm.org/docs/tutorial/LangImpl7.html#adjustments defines a CreateEntryBlockAlloca() helper function that "ensures that the allocas are created in the entry block of the function." It's kid of implied, but I thought I'd ask explicitly: *must* alloca instructions be created in the entry block of a function? - Paul

On 3/29/12 11:32 AM, Paul J. Lucas wrote: > The Kaleidoscope example here: > > http://llvm.org/docs/tutorial/LangImpl7.html#adjustments > > defines a CreateEntryBlockAlloca() helper function that "ensures that the allocas are created in the entry block of the function." > > It's kid of implied, but I thought I'd ask explicitly: *must* alloca instructions be

Hi, I'm incrementing my toy compiler to account for variable mutations around if/else blocks. Reading the Kaleidoscope tutorial, I've learnt that I can substitute the PHI node creation by allocas and retrieving the value later, if needed. The Kaleidoscope example seems to account for one value only, the result of: Value *ThenV = Then->Codegen(); (...) Value *ElseV =

Dear All, Is it legal to have an alloca in a basic block other than a function's entry block? -- John T.

On 4/16/11 7:01 PM, tarun agrawal wrote: > The clone llvm:CloneBasicBlock copies the phi function in the > replicated basic block from the original basic block. After you clone the basic block, you can probably replace the phi instruction with another value of your choice. If you're adding variables, you'll probably want to create them as allocas and use loads and stores to

The clone llvm:CloneBasicBlock copies the phi function in the replicated basic block from the original basic block. I don't want the copy of phi in relplicated block. For now I am creating .bc file with -O0 option so that it doesn't generate phi function in first place. Is this a good approach or there are some other function available for it. Tarun On Sun, Apr 17, 2011 at 5:22 AM, Eli

On 1/21/13 5:22 AM, Alexandru Ionut Diaconescu wrote: > Hello everyone ! > > I am trying to determine for certain Load instructions from my pass > their corresponding Alloca instructions (that can be in other previous > blocks). The chain can be something like : `TargetLoad(var) -> other > stores/loads that use var (or dependencies on var) -> alloca(var).` , > linked

I have a question about when we should apply these pointer aliasing rules. Do the rules tell us when a load/store is safe? "Any memory access must be done through a pointer value associated with an address range of the memory access, otherwise the behavior is undefined." So this means the conversion discussed here is still safe in terms of memory safety, but its meaning after conversion

Hello everyone ! I am trying to determine for certain Load instructions from my pass their corresponding Alloca instructions (that can be in other previous blocks). The chain can be something like : `TargetLoad(var) -> other stores/loads that use var (or dependencies on var) -> alloca(var).` , linked on several basic blocks. Do you know how can I do it? I tried to use the methods from

Hi As shown below, the .\configure script found a version of alloca(): --------------------- configure:20831: checking for working alloca.h configure:20853: gcc -o conftest -g -O2 conftest.c -ldl >&5 configure:20856: $? = 0 configure:20859: test -s conftest configure:20862: $? = 0 configure:20873: result: yes configure:20883: checking for alloca configure:20925: gcc -o conftest -g -O2

John Criswell wrote: > Dear All, > > Is it legal to have an alloca in a basic block other than a function's > entry block? > Thanks everyone for the answers. My original question was referring to the LLVM IR and not standard C. So, the consensus seems to be that it is legal, which makes sense since LLVM supports the C alloca function. FWIW, I'm not inserting allocas

Are there any implicit assumptions about where alloca instructions can appear. I've got a failing test where the only difference between a passing test and a failing test is one application of this code in instcombine: // Convert: malloc Ty, C - where C is a constant != 1 into: malloc [C x Ty], 1 Seems pretty harmless to me. Later on the instcombine code does this: // Scan to the end of

Hi, John I am building a flow sensitive intra-procedural alias analysis(without interprocedural info). So, the first thing I have to consider is where a parameter-pointer or a global-pointer might point to. Then I defined several special Virtual Memory Locations: ALL_MEMORY, GLOBAL_MEMORY, STACK_MEMORY, HEAP_MEMORY. ALL_MEMORY contains GLOBAL_MEMORY, STACK_MEMORY, HEAP_MEMORY. e.g1:

Hello, could any one point me following question. e.g: void foo(int * p) { *p = 0; } Here 'p' may point to all memory location. Could you tell me how to represent the POINT TO set of 'p'? Here is my solution: Introduce a memory-class named: Global_Mem, then p pointed to global_mem. And the MOD set of '*p=0' is