<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Florian,<br>
</p>
<blockquote type="cite"
cite="mid:1A7020FD-C11E-455D-9DB2-882A3E43D545@apple.com">
<div>With VPlan, instead you could add a new VPInstruction opcode
ZextLoad and have a transformation that replaces all `zext
(load)` instructions with the new ZExtLoad one. The cost-model
needs to be taught about this special instruction and how much
it costs. Then you could apply this transformation to an
existing plan and check if the overall cost improved.</div>
<div><br class="">
</div>
<div>Of course there’s also the issue of how to generalize the TTI
APIs to allow for computing the cost of instructions with more
context.
<div><br class="">
</div>
<div>I think we probably want to keep things as generic as
possible, try to model generic concepts and use TTI to decide
whether to use it or not (e.g. see how masked loads/stores are
handled).</div>
</div>
</blockquote>
<p>Hm, so what you are saying is that for any instruction that could
be merged into another one on some architecture, there should be a
new VPInstruction (naturally based on the 'plain' VPInstruction
for that instruction) that symbolises this and would be assigned
the cost 0 by the TTI, or whatever a new cost model would use, of
only the respective architecture. I had to think about this a
bit, but now it makes sense to me. Handling it a smart way, such
that TTIs that do not know about this special case fall back to
what they do for the normal case, would also save us from
generating additional VPlans. And with the load being the
ingredient of the extend, and thus accessible, everything is
available to do some type checking and ensure the merge is doable
for the architecture.<br>
This really helped me to understand how things are supposed to be
working, thanks a lot for explaining!<br>
I do still have a few doubts as to whether this approach might
still bear some risk of over-generating (see my reply to Renato's
email which I'll link you to), but those might simply originate
from me being too cautious because I do not have a good overview
yet of how many (different) examples like the one I mentioned
there are, so how many special cases would have to get their own
VPInstruction flavour.<br>
</p>
<blockquote type="cite"
cite="mid:1A7020FD-C11E-455D-9DB2-882A3E43D545@apple.com">
<div>I am not sure what patterns specifically you are thinking
about, but I think the cost model should just evaluate the cost
of a given plan and not provide anything beyond that. Of course,
this still can mean that there might be certain
recipes/instructions that are not available/profitable on some
targets and we decide to never generate them, based on the
cost-information.</div>
</blockquote>
<p>I was wondering about how one would merge the extend from the
example above into the load without any changes to the VPlan
structure/classes. So basically without the trick of adding
special instructions that you mentioned above. But that does not
seem a nice way to do it.<br class="">
</p>
<blockquote type="cite"
cite="mid:1A7020FD-C11E-455D-9DB2-882A3E43D545@apple.com">
<div>
<blockquote type="cite" class="">
<div class="">
<div class="">
<div class="moz-text-flowed" style="font-family:
-moz-fixed; font-size: 12px;" lang="x-unicode"> I am
considering choosing a topic related to VPlan, possibly
cost modelling, for my Master thesis, with the goal to
present a solution and implement a prototype. <br
class="">
<br class="">
</div>
</div>
</div>
</blockquote>
<br class="">
I am hoping to make some progress on this in the next months
(hopefully the work on modeling the def-use chains between
recipes in VPlan will be wrapped up soon) and I expect there to
be a few moving parts. Not sure what that means for a master
thesis in this area.</div>
</blockquote>
I guess the extend of impact that has on a thesis strongly depends
on what exactly 'this' entails - could you elaborate a bit, please?
Are you planning to do work on a cost model for VPlan, or to change
how VPInstructions and VPRecipes work, or something else?<br>
If I would start working on a thesis named 'Cost modelling with
VPlan' or similar, the first thing to do would be a lot of thinking
and drafting to come up with a good and solid concept. I don't think
that would depend too much on concrete implementation details of
VPlan, as long as the core of the individual components stays the
same...<br>
<br>
Best,<br>
Anna<br>
<pre class="moz-signature" cols="72">
</pre>
</body>
</html>