<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Please correct me if I am wrong, but I thought this discussion was brought up by a temporarily workaround in the cost-model, working around current codegen limitations that needs fixing.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; background: var(--white);">I am asking because Option 1 is what we currently have, and I don't see reasons to depart from this general idea, even if the cost-model
can return Invalid due to a workaround that would hopefully disappear soon. That would mean the assert that the legalisation and cost-model are in sync would need to be skipped, and while that is not ideal, I don't see that as a big problem and I don't see
it as a total departure from Option 1, especially if this is all temporarily.</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; background: var(--white);"><br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
And does this discussion disappear if the codegen issues are fixed? I don't know the scale of the problem/work, but is it not easier to fix that avoiding this cost-model vs. legalisation discussion?</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> llvm-dev <llvm-dev-bounces@lists.llvm.org> on behalf of Sander De Smalen via llvm-dev <llvm-dev@lists.llvm.org><br>
<b>Sent:</b> 10 June 2021 21:50<br>
<b>To:</b> llvm-dev <llvm-dev@lists.llvm.org><br>
<b>Subject:</b> [llvm-dev] LoopVectorizer: Should the cost-model be used for legalisation?</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Hi,<br>
<br>
Last year we added the InstructionCost class which adds the ability to<br>
represent that an operation cannot be costed, i.e. operations that cannot<br>
be expanded by the code-generator will have an invalid cost.<br>
<br>
We started using this information in the Loop Vectorizer for scalable<br>
auto-vectorization. The LV has a legality- and a cost-model stage, which are <br>
conceptually separate concepts with different purposes. But with the <br>
introduction of having valid/invalid costs it's more inviting to use the <br>
cost-model as 'legalisation', which leads us to the following question:<br>
<br>
Should we be using the cost-model to do legalisation?<br>
<br>
'Legalisation' in this context means asking the question beforehand if the <br>
code-generator can handle the IR emitted from the LV. Examples of<br>
operations that need such legalisation are predicated divides (at least<br>
until we can use the llvm.vp intrinsics), or intrinsic calls that have no<br>
scalable-vector equivalent. For fixed-width vectors this legalisation issue<br>
is mostly moot, since operations on fixed-width vectors can be scalarised.<br>
For scalable vectors this is neither supported nor feasible [1].<br>
<br>
This means there's the option to do one of two things:<br>
<br>
[Option 1]<br>
<br>
Add checks to the LV legalisation to see if scalable-vectorisation is<br>
feasible. If so, assert the cost must be valid. Otherwise discard scalable<br>
VFs as possible candidates.<br>
* This has the benefit that the compiler can avoid<br>
calculating/considering VPlans that we know cannot be costed.<br>
* Legalisation and cost-model keep each other in check. If something<br>
cannot be costed then either the cost-model or legalisation was<br>
incomplete.<br>
<br>
<br>
[Option 2]<br>
<br>
Leave the question about legalisation to the CostModel, i.e. if the<br>
CostModel says that <operation> for `VF=vscale x N` is Invalid, then avoid<br>
selecting that VF.<br>
* This has the benefit that we don't need to do work up-front to<br>
discard scalable VFs, keeping the LV design simpler.<br>
* This makes gaps in the cost-model more difficult to spot.<br>
<br>
Note that it's not useful to combine Option 1 and Option 2, because having<br>
two ways to choose from takes away the need to do legalisation beforehand,<br>
and so that's basically a choice for Option 2.<br>
<br>
Both approaches lead to the same end-result, but we currently have a few<br>
patches in flight that have taken Option 1, and this led to some questions<br>
about the approach from both Florian and David Green. So we're looking to<br>
reach to a consensus and decision on what way to move forward.<br>
<br>
I've tentatively added this as a topic to the agenda of the upcoming LLVM<br>
SVE/Scalable Vector Sync-up meeting next Tuesday (June 15th, [2]) as an<br>
opportunity to discuss this more freely if we can get enough people who<br>
actively work on the LV together in that meeting (like Florian and David,<br>
although please forward to anyone else who might have input on this).<br>
<br>
Thanks,<br>
<br>
Sander<br>
<br>
<br>
[1] Expanding the vector operation into a scalarisation loop is currently<br>
not supported. It could be done, but we have done extensive<br>
experimentation with loops that handle each element of a scalable<br>
vector sequentially, but this has never proved beneficial, even when<br>
using special instructions to efficiently increment the predicate<br>
vector. I doubt this will be any different for other scalable vector<br>
architectures, because of the loop control overhead. Also the <br>
insertion/extraction of elements from a scalable vector is unlikely to<br>
be as cheap as for fixed-width vectors.<br>
<br>
[2] <a href="https://docs.google.com/document/d/1UPH2Hzou5RgGT8XfO39OmVXKEibWPfdYLELSaHr3xzo/edit?usp=sharing">
https://docs.google.com/document/d/1UPH2Hzou5RgGT8XfO39OmVXKEibWPfdYLELSaHr3xzo/edit?usp=sharing</a><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
llvm-dev@lists.llvm.org<br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div>
</span></font></div>
</body>
</html>