<div dir="ltr">Hi Chris,<div><br></div><div>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><br></div><div>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><br></div><div>Cheers,</div><div><br></div><div>James</div></div><br><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">clattner@nondot.org</a>> wrote:<br></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">llvm-dev@lists.llvm.org</a>> wrote:<br>
> We'd be keen to help out what the community decides to do here. I personally feel it's reasonable that:<br>
>   - LangRef/DataLayout is updated with semantically coherent changes.<br>
>   - The midend optimizer is updated by someone who cares about those changes and tests are added that use the new DataLayout.<br>
<br>
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>
<br>
Question though: given that approach, wouldn’t that make this whole thing in-tree-testable?<br>
<br>
What would not be testable given the appropriate data layout extensions?<br>
<br>
-Chris<br>
<br>
<br>
</blockquote></div>