<div dir="ltr">On Fri, Jan 25, 2013 at 12:32 AM, Andrew Trick <span dir="ltr"><<a href="mailto:atrick@apple.com" target="_blank" class="cremed">atrick@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="h5"><div><div>On Jan 24, 2013, at 5:19 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank" class="cremed">chandlerc@google.com</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr">On Thu, Jan 24, 2013 at 4:31 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank" class="cremed">hfinkel@anl.gov</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Chandler,<br>
<br>
Does your recent SimplifyCFG work affect this proposal?<br></blockquote><div><br></div><div>Only a tiny bit.</div><div><br></div><div>My work was to remove some hard-coded assumptions, and manually rolled cost models into thresholds and the TTI-based cost model. This shouldn't significantly change how the code is SimplifyCFG works or the tradeoffs LLVM makes. It continues to rely on something like early if-conversion for forming anything but trivial predicated formations.</div>

<div><br></div><div>It should do two things (modulo bugs of course):</div><div>1) It makes the existing "if-conversion"-like functionality in SimplifyCFG both more correct and consistent. It will no longer fail to convert equally trivial constructs, and it will no longer mistakenly convert expensive constructs.</div>

<div><br></div><div>2) It makes the mechanism for the transformation itself a bit more flexible and robust, so that *if* we ever have a reason to do more of this in the IR, the code can actually handle it.</div>
<div><br></div><div><br></div><div>I still thing it is worth investigating the pattern I described, and I think Dan is thinking about some of these issues.... But there are still some hard problems to solve to make it feasible & profitable. =]</div>

</div></div></div></blockquote><br></div></div></div><div>Most of the code changes to improve metrics/heuristics so far look great...</div></div></blockquote><div><br></div><div style>Awesome. Yell if that changes, but the what I've been poking at thus far, I'm really trying to stay on the extreme end of conservative and non-controversial.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>but to address your future plans for TTI and respond to the patch that started this thread:</div>
</div></blockquote><div><br></div><div style>I don't actually have a plan. I had an idea. I've also talked about it with Dan, and I think he was going to think more and look into whether it actually works, if so how, and write it up. We'll see.</div>
<div style><br></div><div style>Anyways, to the more general comments here:</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">
<div><br></div><div><div>Early passes, like SimplifyCFG, whose job is to canonicalize IR should try to avoid using heuristics driven by thresholds. No disagreement I'm sure. But along the same lines, when we do need heuristics to avoid IR bloat, they should be derived purely from the IR, not TTI. This applies to any pass that we would like to run before we start lowering. i.e. before the late IR loop optimizations (loop-idiom, vectorize, partial unroll). This way, the IR doesn't deviate much across targets until we start running passes that actually care about the target. If I'm writing an optimization that I think is target-independent, I'd like it to work the same way across targets without worrying about seemingly random changes to the IR. I've wasted plenty of time debugging issues in LSR that are affected in unpredictable ways by target info. That problem will be greatly magnified as we start moving TTI earlier.</div>
<div><br></div><div>Regardless, we need a way of checking whether certain intrinsics are always free, independent of TTI. And with that, I'm guessing a purely IR-based heuristic work nearly as well as one based on TTI. If the actual mechanism to achieve this is to simply force NoTTI for "early" passes, that's fine--but does seem decepetive.</div>
<div><br></div><div>You may disagree with me on inlining. I concede that we might make some exceptions, but the exceptions should be justifiable based on experience.</div></div></div></blockquote><div><br></div><div style>
At a high level, I'm a bit torn here. There are lots of places where I agree, but also quite a few where I disagree... But I don't think in any way that impacts this patch, SimplifyCFG, or other stuff going on right now.</div>
<div style><br></div><div style>I think this is really just part of a longer discussion about how target information should and shouldn't be used within IR passes, and how to structure things, and we'll have a hard time even discussing the issues in the context of this thread. =] Certainly, I think every interesting example I come up with has *nothing* to do with this thread.</div>
<div style><br></div><div style>At some point, I'd like to find a time when we can sit down and really dig into this and come up with a good model, but hopefully there is no real urgency here... At least, I don't expect either fast or radical changes w.r.t. much of these pieces of the optimizer.</div>
</div></div></div>