[LLVMdev] make DataLayout a mandatory part of Module
listmail at philipreames.com
Thu Jan 30 09:55:04 PST 2014
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.
More information about the llvm-dev