Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Nick Lewycky <nlewycky <at> google.com>
Subject: make DataLayout a mandatory part of Module
Newsgroups: gmane.comp.compilers.llvm.devel
Date: Wednesday 29th January 2014 23:40:33 UTC (over 3 years ago)
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?

Nick
 
CD: 5ms