<div dir="ltr">On 25 January 2013 23:03, Nadav Rotem <span dir="ltr"><<a href="mailto:nrotem@apple.com" target="_blank">nrotem@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 class="im"><span style="color:rgb(34,34,34)">Yes. This is a limitation of the current API.  The design decision behind it was that in many cases you want to know the cost of IR before you generate it.</span></div></blockquote>
<div><br></div><div style>That makes sense.</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><span style="color:rgb(34,34,34)">Also, we wanted to rely on tables as much as possible. We did not want to write code to resemble ISel in order to estimate the cost. Is this something that we can live with ?</span></div>
</blockquote><div><br></div><div style>It depends on the final design intentions. If these costs are only ever going to be used by the vectorization, or if other optimizations are going to start using TargetTransformInfo for cost information, than yes, it makes sense to begin focusing cost models on TTI. But if other passes call TL directly, then we might re-think the strategy.</div>
<div style><br></div><div style>It looks to me that only lowering would need to call TL's costs, since they can be different than a more high level cost, and possibly assume that the code is already valid and checked, which is not the case for most transformations, including the vectorization. I think this is more or less what you were saying before.</div>
<div style><br></div><div style>I'll give it a few tries and send to the list so we can discuss with more concrete implementations.</div><div style><br></div><div style>cheers,</div><div style>--renato</div></div><br>
</div></div>