<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">On Nov 6, 2019, at 7:43 AM, James Molloy <<a href="mailto:james@jamesmolloy.co.uk" class="">james@jamesmolloy.co.uk</a>> wrote:<div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">Hi Chris,<div class=""><br class=""></div><div class="">SelectionDAGBuilder, DAGCombine and anything in CodeGen (but I can't think of any examples there offhand, come to think of it). I must admit that until I wrote up that email, it hadn't quite occurred to me how much of the change would be testable. After the writeup, it doesn't sounds quite as contentious as I considered it.</div><div class=""><br class=""></div><div class="">SelectionDAGBuilder is a simple non-invasive change to visitGetElementPtrInst(); DAGCombiner may have some nasties lurking in it. Inability to test a DAGCombine is hardly a new problem though :)</div></div></div></blockquote><div><br class=""></div><div>Yeah, that was my sense. Here is another crazy question - just to probe the limits of your tolerance here :-).</div><div><br class=""></div><div>Assuming we added a new field to DataLayout, what would the emergent behavior be for an “invalid" configuration given a target?</div><div><br class=""></div><div>Let me consider an existing situation: what would happen if we shoved a .ll file with a datalayout specifying ‘big endian’ into X86 or some other little endian target?</div><div><br class=""></div><div>The answer (assuming no hard error) is that all the target independent logic would still key off of this, and the target specific logic wouldn’t. Given that the testing goal is to generalize the target independent logic and test it, this emergent behavior may be enough to test the (e.g.) SelectionDAGBuilder changes with some existing target.</div><div><br class=""></div><div>-Chris</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Cheers,</div><div class=""><br class=""></div><div class="">James</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 5 Nov 2019 at 21:52, Chris Lattner <<a href="mailto:clattner@nondot.org" class="">clattner@nondot.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Nov 4, 2019, at 4:00 PM, James Molloy via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class="">
> We'd be keen to help out what the community decides to do here. I personally feel it's reasonable that:<br class="">
> - LangRef/DataLayout is updated with semantically coherent changes.<br class="">
> - The midend optimizer is updated by someone who cares about those changes and tests are added that use the new DataLayout.<br class="">
<br class="">
This makes perfect sense to me - if you want the mid-level optimizer to be aware of this, then it makes sense for it to be part of DataLayout.<br class="">
<br class="">
Question though: given that approach, wouldn’t that make this whole thing in-tree-testable?<br class="">
<br class="">
What would not be testable given the appropriate data layout extensions?<br class="">
<br class="">
-Chris<br class="">
<br class="">
<br class="">
</blockquote></div>
</div></blockquote></div><br class=""></body></html>