
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 9, 2012, at 6:10 PM, Chandler Carruth wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Mon, Jan 9, 2012 at 5:34 PM, Jakob Stoklund Olesen <span dir="ltr"><<a href="mailto:stoklund@2pi.dk">stoklund@2pi.dk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div id=":4oo">As always, test cases for this stuff are insane.<br></div></blockquote></div><br><div>This is starting to worry me. How will we ever catch regressions? It seems like there has to be a way to write test cases for this kind of stuff, even if it means digging out and exposing more of the innards... Maybe this is a place where unit tests could actually work? I haven't looked at it at all, I'm just looking for a way to write non-insane test cases for this (clearly tricky) part of the backend....</div>

</blockquote></div><br><div>The particular issue is exposed when an instruction is at a function offset == 2 (mod 4), and it references an 8-byte aligned constant pool entry, and there is at least 4k of basic block both before and after the instruction.</div><div><br></div><div>While it may be practical to write a unit test for that particular case, it seems like a dead end for most other cases. A codegen pass depends on a lot of data structures being in place, and generating MI IR programmatically is horrible.</div><div><br></div><div>As we discussed before, the best solution is to feed serialized MI IR directly into the pass. It's just a small matter of engineering.</div><div><br></div><div>/jakob</div><div><br></div></body></html>