<br><br><div class="gmail_quote">On Wed Oct 22 2014 at 12:33:53 PM Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Oct 20, 2014, at 10:41 PM, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>> wrote:<br>
>>> So the storage for DataLayout right now is on a per-subtarget basis.<br>
>>> I.e. if you don't construct one in the module the backend will make<br>
>>> one up based on information in the subtarget (everything from<br>
>><br>
>> I think this is what Chandler is proposing to fix: every module will have a DataLayout string.<br>
>><br>
><br>
> Right. I was figuring there'd be some way of having the backend<br>
> specify it if there isn't one in the module IR - or a way of calling<br>
> into the backend to generate one up since memorizing all of the<br>
> possible target layouts for all of the targets would probably be a<br>
> pain. These bits would probably be off of the TargetMachine right now.<br>
> It'd make moving the DataLayout string onto the TargetMachine easier<br>
> later if we decide to do that.<br>
<br>
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.<br>
<br>
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.<br><br></blockquote><div><br></div><div>Yep. That's basically what I was suggesting. :)</div><div><br></div><div>Go total agreement!</div><div><br></div><div>-eric </div></div>