[llvm-dev] [RFC] Goals for VPlan-based cost modelling

Anna Sophia Welker via llvm-dev
Mon, 02 Nov 2020 09:48:51 -0000

Hi Florian,

> 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.
>
> 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.
>
> 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).

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.
This really helped me to understand how things are supposed to be
working, thanks a lot for explaining!
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.

> 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.

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.

>> 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.
>>
>
> 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.
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?
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...

Best,
Anna

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201102/8175b26d/attachment.html>