Hey, if you can get it to work fast with a min-cut formulation on programs with lots of fences, that would be awesome :)<br><div>As I told JF, I haven't played with such formulations in about 7 years, so it's entirely possible the world is a better place now.</div><div><br></div><div>They are certainly conceptually simpler to work with and reason about :)</div><div><br></div><br><div class="gmail_quote">On Wed Nov 05 2014 at 8:08:15 AM JF Bastien <<a href="mailto:jfb@chromium.org">jfb@chromium.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(Discussing this offline with Danny)<br>
<br>
I'd like measurements for your approach. I'm not sure it'll be slow on big functions because your graph is a subset of all the IR in the function.<br>
<br>
As we discussed, csmith should be able to generate big functions with lots of fences. Measuring runtime at different CFG size and fence+surrounding memory size would be useful, and basic profiling would show where overheads are in the current code.<br>
<br>
I think that should inform whether another algorithm should be tried.<br>
<br>
<a href="http://reviews.llvm.org/D5758" target="_blank">http://reviews.llvm.org/D5758</a><br>
<br>
<br>
</blockquote></div>