<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 14, 2015 at 10:44 AM Tim Northover <<a href="mailto:t.p.northover@gmail.com">t.p.northover@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 14 December 2015 at 09:20, Eric Christopher via cfe-commits<br>
<<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>> wrote:<br>
> I understand the conflicting priorities here for sure. You'd like a test that's as minimal as possible, without having to depend on external (to clang) libraries here. I really would appreciate it if you'd make the test not rely on mem2reg etc so we can be sure that clang's code generation is the thing tested here and not the optimizer. Making sure that the unoptimized output reduces properly would be a great opt test for the backend though.<br>
<br>
I think I'm with Alexandros here. Tests based on raw Clang output are<br>
horrific to write and maintain. They end up relying on implementation<br>
details like just how many allocas and reloads Clang decides it needs<br>
for some random expression, even working out whether the test is<br>
correct changes from a pretty trivial eyeballing to keeping track of<br>
dozens of lines of data-flow.<br><br></blockquote><div><br></div><div>I don't think it's going to be even vaguely that bad here and that you're blowing it a bit out of proportion. Also you're relying on the behavior of backend optimizations to figure out what's going on with your clang IR generation which also seems less than optimal. It does make the tests a little harder to write, but having done a bunch of them it's not that bad.</div><div><br></div><div>-eric</div><div> </div></div></div>