[LLVMdev] make DataLayout a mandatory part of Module

Nick Lewycky nlewycky at google.com
Wed Jan 29 15:40:33 PST 2014

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.

The cost to keeping this feature around is that we have to pass around the
DataLayout object in many places, test for its presence, in some cases
write different optimizations depending on whether we have DataLayout, and
in the worst case I can think of, we have two different canonical forms for
constant expressions depending on whether DL is present. Our canonical IR
is different with and without datalayout, and we have two canonicalizers
fighting it out (IR/ConstantFold.cpp and Analysis/ConstantFolding.cpp).

I'm trying to force the issue. Either this is a useful feature to maintain
in which case I want to see a design on how to defer ABI decisions until a
later point in time, or else we do not support it and target triple and
target datalayout become a mandatory part of a valid Module again. I think
the correct direction is to make them mandatory, but this is a large change
that warrants debate.

If we decide that target information should be a mandatory part of a
module, there's another question about what we should do with existing .bc
and .ll files that don't have one. Load in a default of the host machine?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140129/8660dd36/attachment.html>

More information about the llvm-dev mailing list