[LLVMdev] make DataLayout a mandatory part of Module

[Philip Reames]

On 1/29/14 3:40 PM, Nick Lewycky wrote:
> The LLVM Module has an optional target triple and target datalayout. 
> Without them, an llvm::DataLayout can't be constructed with meaningful 
> data. The benefit to making them optional is to permit optimization 
> that would work across all possible DataLayouts, then allow us to 
> commit to a particular one at a later point in time, thereby 
> performing more optimization in advance.
>
> This feature is not being used. Instead, every user of LLVM IR in a 
> portability system defines one or more standardized datalayouts for 
> their platform, and shims to place calls with the outside world. The 
> primary reason for this is that independence from DataLayout is not 
> sufficient to achieve portability because it doesn't also represent 
> ABI lowering constraints. If you have a system that attempts to use 
> LLVM IR in a portable fashion and does it without standardizing on a 
> datalayout, please share your experience.
Nick, I don't have a current system in place, but I do want to put 
forward an alternate perspective.

We've been looking at doing late insertion of safepoints for garbage 
collection.  One of the properties that we end up needing to preserve 
through all the optimizations which precede our custom rewriting phase 
is that the optimizer has not chosen to "hide" pointers from us by using 
ptrtoint and integer math tricks. Currently, we're simply running a 
verification pass before our rewrite, but I'm very interested long term 
in constructing ways to ensure a "gc safe" set of optimization passes.

One of the ways I've been thinking about - but haven't actually 
implemented yet - is to deny the optimization passes information about 
pointer sizing.  Under the assumption that an opto pass can't insert an 
ptrtoint cast without knowing a safe integer size to use, this seems 
like it would outlaw a class of optimizations we'd be broken by.

My understanding is that the only current way to do this would be to not 
specify a DataLayout.  (And hack a few places with built in 
assumptions.  Let's ignore that for the moment.)  With your proposed 
change, would there be a clean way to express something like this?

p.s. From reading the mailing list a while back, I suspect that the SPIR 
folks might have similar needs.  (i.e. hiding pointer sizes, etc..)  
Pure speculation on my part though.

Philip