[LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?
clattner at apple.com
Wed Oct 22 12:33:53 PDT 2014
On Oct 20, 2014, at 10:41 PM, Eric Christopher <echristo at gmail.com> wrote:
>>> So the storage for DataLayout right now is on a per-subtarget basis.
>>> I.e. if you don't construct one in the module the backend will make
>>> one up based on information in the subtarget (everything from
>> I think this is what Chandler is proposing to fix: every module will have a DataLayout string.
> Right. I was figuring there'd be some way of having the backend
> specify it if there isn't one in the module IR - or a way of calling
> into the backend to generate one up since memorizing all of the
> possible target layouts for all of the targets would probably be a
> pain. These bits would probably be off of the TargetMachine right now.
> It'd make moving the DataLayout string onto the TargetMachine easier
> later if we decide to do that.
I think I see what you’re saying: you’re saying that it doesn’t make sense for each target to know the DL string *and* to require each frontend to know the DL string for each target it supports.
If that’s the problem you’re trying to solve, the approach I would take is to have Clang (and other frontends) query the TargetMachine directly when it is setting up the module. This will give you the layering that you’re looking for, and avoid duplicating the magic strings.
More information about the llvm-dev