<html>
    <head>
      <base href="https://bugs.freedesktop.org/">
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Add FP64 support to the i965 shader backends"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=92760#c91">Comment # 91</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Add FP64 support to the i965 shader backends"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=92760">bug 92760</a>
              from <span class="vcard"><a class="email" href="mailto:jasuarez@igalia.com" title="Juan A. Suarez <jasuarez@igalia.com>"> <span class="fn">Juan A. Suarez</span></a>
</span></b>
        <pre>(In reply to Francisco Jerez from <a href="show_bug.cgi?id=92760#c89">comment #89</a>)
<span class="quote">> (In reply to Juan A. Suarez from <a href="show_bug.cgi?id=92760#c88">comment #88</a>)
> >[..]
> > Related with this topic, current liveness analysis code (and also DCE
> > optimization) just ignore the types when dealing with the swizzles. This
> > works fine, except when reading/writing a channel from DF type (64-bit
> > channel), and write/read it later as F (32-bit channel).
> > 
> > For instance, for this piece is code:
> > 
> >     mov(8) vgrf3.0.x:UD[1], 2576980378U[1] NoMask
> >     mov(8) vgrf3.0.y:UD[1], 1071225241U[1] NoMask
> >     mov(8) vgrf3.1.x:UD[1], 2576980378U[1] NoMask
> >     mov(8) vgrf3.1.y:UD[1], 1071225241U[1] NoMask
> >     mov(8) vgrf2.0.xy:DF[2], vgrf3.0.xxxx:DF[2]
> > 
> > Our liveness analysis just decide vgrf3.0.y channel is not live anymore and
> > thus DCE removes it. That is because in latest instruction it doesn't
> > realize vgrf3.0.x:DF is reading both vgrf3.0.x:F and vgrf3.0.y:F.
> > 
> > In order to avoid introducing too many changes in our current code, I've
> > added a pair of commits[1][2] that basically try to check if a 32-bit
> > channels was previously read as 64-bit (and the other way around). This
> > seems to fix above problem.

> Seems very sketchy.  You need to fix the current dataflow analysis logic to
> flip/check as many bits per channel from the live, use or def bitsets as the
> corresponding source or destination datatype takes, just like the FS back-end
> handles multi-GRF defs and uses.
> </span >

Thanks for the feedback!

I threw away the changes done, and re-did it following your suggestion. Now, it
flips/checks as many bits as the datatypes require.

I find this implementation more easy to understand.

Commit is in
<a href="https://github.com/Igalia/mesa/commit/59fd1cc6b99dc993e0da772674a57390a54955f3">https://github.com/Igalia/mesa/commit/59fd1cc6b99dc993e0da772674a57390a54955f3</a></pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the QA Contact for the bug.</li>
      </ul>
    </body>
</html>