<div dir="ltr">Hi Renato,<div><br></div><div>Thanks for your reply.</div><div>IIUC. If I could lower LLVM IR to Asm correctly under my type system design, there should be no problem with it.</div>Another concern I have is that llvm.vscale intrinsic is designed to return integer value. Should we relax it to return float or something else?<div>Thanks.</div><div><br></div><div>Kai</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 8, 2020 at 5:36 PM Renato Golin <<a href="mailto:rengolin@gmail.com">rengolin@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 8 Apr 2020 at 04:23, Kai Wang <<a href="mailto:kai.wang@sifive.com" target="_blank">kai.wang@sifive.com</a>> wrote:<br>
> If we apply the type system pointed out by Renato, is the vector type <vscale x 1 x i16> legal? If we decide that <vscale x 1 x i16> is a fundamentally impossible type, does it contrary to the philosophy of LLVM IR as reasonably target-independent IR? I do not get the point of your argument.<br>
<br>
Hi Kai,<br>
<br>
Don't worry about target-independent IR in your design of intermediate<br>
passes or lowering.<br>
<br>
By the time the front-end lowers to LLVM IR, it already has, often<br>
irreversible, target-specific knowledge in it.<br>
<br>
If by some stroke of luck that doesn't happen, then using "<vscale x<br>
anything>" is enough indication that you should not try to lower that<br>
onto a target that it wasn't specifically aimed at.<br>
<br>
No one expects the middle-end to be target-neutral. That's the whole<br>
point of constantly asking target-specific machinery (like TTI) about<br>
what's possible or what's "good" and what's not.<br>
<br>
More importantly, the closer you are to the end of the pass pipeline,<br>
the closer the IR is to machine IR. It's not uncommon, and often<br>
expected, to see "just the right amount of shuffles" to match lowering<br>
patterns into MIR and then Asm.<br>
<br>
IIRC, OpenCL or some other parallel-compute/graphic oriented pipeline<br>
does use odd vector shapes and legalise them later on.<br>
<br>
I may be severely outdated in my opinion, and happy to be corrected,<br>
but I don't think it would be totally egregious to carry on with<br>
(whole numbered) vector shapes that aren't strictly legal, as long as<br>
you guarantee that *any* such pattern gets correctly legalised by the<br>
lowering.<br>
<br>
If you can make the adversarial cases performing on top of that, it's<br>
a bonus, not a target.<br>
<br>
Hope this helps.<br>
<br>
cheers,<br>
--renato<br>
</blockquote></div>