<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10pt" ><div dir="ltr" ><div>We propose introducing two new intrinsics: llvm.variable.length.load and llvm.variable.length.store.<br>We have implemented the infrastructure for defining and lowering these in this phabricator patch: <a href="https://reviews.llvm.org/D86693" >https://reviews.llvm.org/D86693</a></div>
<div> </div>
<div>These represent the semantics of loading and storing a variable number of bytes to a fixed-width register;<br>in effect, a masked load or store where the only active lanes are given by a contiguous block.</div>
<div> </div>
<div>There are a few reasons for separately representing this kind of operation, even though as noted it can be represented by a subset of masked loads and stores.</div>
<div> </div>
<div>- For targets that have separate hardware support for this kind of operation, it makes it easier to generate an optimal lowering. We are currently working on enabling this for some PowerPC subtargets. In particular, there are some targets that support this kind of operation but not masked loads and stores in general, including Power9.</div>
<div> </div>
<div>- Scalarization of this pattern can be done using a number of branches logarithmic in the width of the register, rather than the linear case for general masked operations.</div>
<div>- Scalarized residuals of vectorized loops tend to employ these semantics (tail-folding in particular), so this infrastructure can be used to make more specific optimization decisions for lowering loop residuals. This also pulls out the logic of how to represent and lower such semantics from the loop vectorizer, allowing for better separation of concerns. Our group is currently working on implementing some of these optimizations in the loop vectorizer.</div>
<div> </div>
<div>- Representing these semantics using current masked intrinsics would require introducing intermediate steps to generate the appropriate bitmasks, and then detecting them during lowering. This introduces nontrivial complexity that we want to avoid. If it isn't possible to detect all cases during lowering by inspecting the AST, expensive runtime checks would then have to be introduced.</div>
<div> </div>
<div> </div>
<div>Please refer to the phabricator patch for our implementation, which includes intrinsic definitions, new SDAG nodes, and support for type widening and scalarization.</div>
<div> </div></div></div><BR>