<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 27, 2019, at 9:28 AM, Philip Reames via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class=""><p class=""><br class="">
</p>
<div class="moz-cite-prefix">On 9/27/19 7:33 AM, Matt Arsenault via
llvm-dev wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:9D83B63C-5D2E-41D6-AED9-BB2E0918F3FD@gmail.com" class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<br class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On Sep 27, 2019, at 09:07, Björn Pettersson A
via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class=""><span style="caret-color: rgb(0, 0, 0);
font-family: Helvetica; font-size: 12px; font-style:
normal; font-variant-caps: normal; font-weight: normal;
letter-spacing: normal; text-align: start; text-indent:
0px; text-transform: none; white-space: normal;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
text-decoration: none; float: none; display: inline
!important;" class="">Obviously we do not store into two
locations (it is still a single two byte store).</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica;
font-size: 12px; font-style: normal; font-variant-caps:
normal; font-weight: normal; letter-spacing: normal;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px; text-decoration: none;" class="">
<span style="caret-color: rgb(0, 0, 0); font-family:
Helvetica; font-size: 12px; font-style: normal;
font-variant-caps: normal; font-weight: normal;
letter-spacing: normal; text-align: start; text-indent:
0px; text-transform: none; white-space: normal;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
text-decoration: none; float: none; display: inline
!important;" class="">So is it (always) correct to
interpret the list of MachineMemOperands as the
instruction will store to one of the locations?</span></div>
</blockquote>
</div>
<div class=""><br class="">
</div>
I think it’s bug to have multiple memory operands if the
instruction only accesses one location. The operands should have
been merged in some way unless the instruction can truly access
two distinct addresses</blockquote></div></div></blockquote>I would actually expect gather/scatter loads/stores to have multiple MMOs but according to SelectionDAG we generate just one, which seems technically incorrect.</div><div><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><p class="">I'm a bit less sure of this. It's on the surface reasonable, but
there are some interesting questions.<br class="">
</p><p class="">We definitely interpret a list of MMOs as indicating a set of
locations which are possibly(?) accessed. The only piece I'm
unsure about is that the existence of an MMO requires the access
occurs. If we do, that raises some interesting consistency
questions for cases such as:</p>
<ul class="">
<li class="">Load/Store merging (a superset of the branch folding case)</li>
<li class="">Predicate loads and stores (since the access may not happen)</li>
<li class="">Load/stores in dead code (i.e. the typical UB contradiction
cases)</li>
<li class="">Instructions w/multiple accesses to the same MMO combined
w/constant memory to imm folding which only handles some cases</li></ul></div></div></blockquote>Maybe this should be specified properly somewhere, like a MIR langref. In GlobalISel we rely on MMOs being present and correct for legalization, which bakes in a 1-1 mapping assumption, at least for simple loads & stores.<br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><ul class="">
</ul><p class="">I'm tempted to suggest we treat the list of MMOs as a potential
superset of the implied access, not a direct one-to-one mapping.</p><p class="">(None of this should imply branch folding shouldn't merge the
MMOs. That would just become an optimization quality issue, not a
correctness one.)<br class="">
</p><p class="">Philip<br class="">
</p><p class=""><br class="">
</p>
<blockquote type="cite" cite="mid:9D83B63C-5D2E-41D6-AED9-BB2E0918F3FD@gmail.com" class="">
<div class=""><br class="">
</div>
<div class="">-Matt</div>
<br class="">
<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>
</div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></body></html>