[LLVMdev] Opt pass for collecting static memory allocations (allocas and globals) to one big memory area.

John Criswell criswell at illinois.edu
Mon Mar 11 12:00:24 PDT 2013

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 you use SAFECode, I'd recommend hacking it to use complete checks.

If you're wanting to know that a piece of code accesses only certain 
types of memory (e.g., globals and stack but not heap), then you either 
need to write something yourself or modify the aforementioned tools.

> 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 contiguous form to be able to just to add checks 
> to loads/sotres that address is inside that memory structure.

No, I don't believe such a transform exists, but it should be pretty 
easy to write.  Just be forewarned that you can't safely promote allocas 
to global variables when they're used in loops or in functions that can 
be called recursively.  You must either check for these conditions or 
assume a priori that you code does not do these things.

-- John T.

> Does anyone know if there already exist some pass which does something 
> like this (collects static allocations) or should I write this from 
> the scratch ? Does the idea sound reasonable at all ?
> Cheers, Mikael Lepistö
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130311/51b92872/attachment.html>

More information about the llvm-dev mailing list