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

[Anna Sophia Welker via llvm-dev]

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>