<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 20, 2014 at 9:51 AM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank" class="cremed">clattner@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On Oct 19, 2014, at 1:22 AM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com" class="cremed">chandlerc@gmail.com</a>> wrote:<br>
<br>
> I've just wasted a day chasing my tail because of subtleties introduced to handle the optionality of the DataLayout. I would like to never do this again. =]<br>
><br>
> We now have this attached to the Module with just a flimsy faked-up pass to keep APIs consistent. So, is there any problem with beginning down the path of:<br>
><br>
> 1) Synthesizing a "default" boring DataLayout for all modules that don't specify one.<br>
> 2) Changing the APIs to make it clear that this can never be missing and is always available.<br>
> 3) Start ripping out all of the complexity in the compiler dealing with this.<br>
<br>
</span>+1 from me.  The theoretical blue-sky reasons for working with a module that has no datalayout never happened and almost certainly never will.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>Agreed. The DataLayout should move (back) to the TargetMachine and live there (I'm doing that part right now). I don't particularly want to put it on the module because of (admittedly pie in the sky) plans of being able to compile a module with two target machines at the same time.</div><div><br></div><div>-eric </div></div><br></div></div>