<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 1/7/21 10:40 AM, Reid Kleckner via
llvm-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACs=ty+KD-K73UcxPxJh64xRiFheAr03dRay-cF0hPXyV_Z3WQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">I think your approach is probably the best, but I
think it's worth sketching out an alternative approach using
token that wouldn't require verifier changes.
<div><br>
</div>
<div>If you want to avoid verifier changes, the token type
already gives you what you want: it is opaque, cannot be
loaded and stored or phid, and can serve as a "value
multiplexer". You could invent new intrinsics to extract the
values you need. The source of a token cannot be obscured, so
lowering can always look through a token operand, find the
source, and link up the correct SDValue in codegen. The
downside is that all this solution would be opaque to the
mid-level optimizers. They already understand insertvalue and
extractvalue. So, I don't think this is a good way to go, but
it's worth considering.</div>
<div><br>
</div>
<div>I think, if we all agree that first class aggregates that
can be loaded, stored, and phi'd, were a historical design
mistake, then your original proposed solution is a step in the
direction of removing FCA support.</div>
<div><br>
</div>
<div>I wonder if, in the future, it would be possible to
auto-upgrade IR that contains these FCA operations by
splitting them into scalar operations, and we could make the
verifier reject all of these undesired operations.</div>
</div>
</blockquote>
+1 to this goal. Getting there might be tricky, and take a while,
but definite +1 to the direction. <br>
<blockquote type="cite"
cite="mid:CACs=ty+KD-K73UcxPxJh64xRiFheAr03dRay-cF0hPXyV_Z3WQ@mail.gmail.com"><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Jan 6, 2021 at 2:27 PM
Craig Topper via llvm-dev <<a
href="mailto:llvm-dev@lists.llvm.org" moz-do-not-send="true">llvm-dev@lists.llvm.org</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">
<div dir="ltr">
<div>Hi,</div>
<div><br>
</div>
RISCV vector intrinsics have a need to return multiple
scalable vector values. We plan to use this to return
multiple results from segment load intrinsics. These
instructions conceptually load multiple separate registers.
I believe SVE has similar load intrinsics, but they use wide
scalable vectors that get split during type legalization. We
are struggling to do the same since we already use the size
of the fixed part of a scalable vector to determine LMUL
size. This means we have legal scalable vector types with
different fixed part sizes. This makes it very difficult for
type legalization to split a wide vector type for a segment
load into the correct number of pieces. We feel that
returning multiple results and avoiding the type legalizer
is an easier path.
<div><br>
<div>Unfortunately, supporting multiple scalable vectors
being returned from an intrinsic requires scalable
vectors to be allowed in structs. We would disallow such
structs to be used by loads/stores/allocas/geps which
would avoid needing to determine the offsets of any of
the fields in the struct.</div>
<div><br>
</div>
<div>I've posted an initial patch for the IR and verifier
portions of this here <a
href="https://reviews.llvm.org/D94142" target="_blank"
moz-do-not-send="true">https://reviews.llvm.org/D94142</a></div>
<div><br>
</div>
<div>We would appreciate any feedback on this direction.</div>
<div>
<div><br>
</div>
<div>Thanks,<br clear="all">
<div>
<div dir="ltr">~Craig</div>
</div>
</div>
</div>
</div>
</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
<a
href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
</body>
</html>