<div dir="ltr">Gather is creating a single MMO using the "uniform base" with the scalar size of the gather. The indices aren't factored in. So I don't think its even pointing to the right place.<div><br clear="all"><div><div dir="ltr" data-smartmail="gmail_signature">~Craig</div></div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 3, 2019 at 11:08 PM Amara Emerson via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">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><br><div><br><blockquote type="cite"><div>On Sep 27, 2019, at 9:28 AM, Philip Reames via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br><div>
  
    
  
  <div bgcolor="#FFFFFF"><p><br>
    </p>
    <div>On 9/27/19 7:33 AM, Matt Arsenault via
      llvm-dev wrote:<br>
    </div>
    <blockquote type="cite">
      
      <br>
      <div><br>
        <blockquote type="cite">
          <div>On Sep 27, 2019, at 09:07, Björn Pettersson A
            via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>
            wrote:</div>
          <br>
          <div><span style="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;text-decoration:none;float:none;display:inline">Obviously we do not store into two
              locations (it is still a single two byte store).</span><br style="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;text-decoration:none">
            <span style="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;text-decoration:none;float:none;display:inline">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><br>
      </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"><div><div bgcolor="#FFFFFF"><p>I'm a bit less sure of this.  It's on the surface reasonable, but
      there are some interesting questions.<br>
    </p><p>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>
      <li>Load/Store merging (a superset of the branch folding case)</li>
      <li>Predicate loads and stores (since the access may not happen)</li>
      <li>Load/stores in dead code (i.e. the typical UB contradiction
        cases)</li>
      <li>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><blockquote type="cite"><div><div bgcolor="#FFFFFF"><ul>
    </ul><p>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>(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>
    </p><p>Philip<br>
    </p><p><br>
    </p>
    <blockquote type="cite">
      <div><br>
      </div>
      <div>-Matt</div>
      <br>
      <fieldset></fieldset>
      <pre>_______________________________________________
LLVM Developers mailing list
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
    </blockquote>
  </div>

_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br></div></blockquote></div><br></div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div></div>