<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 19, 2015 at 1:25 PM, Francisco Jerez <span dir="ltr"><<a href="mailto:currojerez@riseup.net" target="_blank">currojerez@riseup.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> writes:<br>
<br>
> On Thu, Feb 19, 2015 at 12:13 PM, Francisco Jerez <<a href="mailto:currojerez@riseup.net">currojerez@riseup.net</a>><br>
> wrote:<br>
><br>
>> Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> writes:<br>
>><br>
>> > On Fri, Feb 6, 2015 at 4:01 PM, Francisco Jerez <<a href="mailto:currojerez@riseup.net">currojerez@riseup.net</a>><br>
>> > wrote:<br>
>> ><br>
>> >> Hey Matt,<br>
>> >><br>
>> >> Matt Turner <<a href="mailto:mattst88@gmail.com">mattst88@gmail.com</a>> writes:<br>
>> >><br>
>> >> > On Fri, Feb 6, 2015 at 6:42 AM, Francisco Jerez <<br>
>> <a href="mailto:currojerez@riseup.net">currojerez@riseup.net</a>><br>
>> >> wrote:<br>
>> >> >> MRFs cannot be read from anyway so they cannot possibly be a valid<br>
>> >> >> source of LOAD_PAYLOAD.<br>
>> >> >> ---<br>
>> >> ><br>
>> >> > The function only seems to test inst->dst.file == MRF. I don't see any<br>
>> >> > code for handling MRF sources. What am I missing?<br>
>> >><br>
>> >> That test is for "handling" MRF sources -- More precisely, it's<br>
>> >> collecting the writemask and half flags for MRF writes, which can only<br>
>> >> possibly be useful if we're going to use them later on to read something<br>
>> >> out of an MRF into a payload, which we shouldn't be doing in the first<br>
>> >> place.<br>
>> >><br>
>> >> Aside from simplifying the function somewhat, that allows us to drop the<br>
>> >> 16 register gap reserved for MRFs at register offset zero, what will<br>
>> >> allow us to drop the vgrf_to_reg[] offset calculation completely (also<br>
>> >> in split_virtual_grfs()) in a future patch (not sent for review yet).<br>
>> >><br>
>> ><br>
>> > No, we do read from MRF's sort-of...  Send messages have an implicit<br>
>> "read"<br>
>> > from an MRF.<br>
>><br>
>> Heh, and that's pretty much the only way you "read" from it.<br>
>><br>
>> > This was written precicely so that we could use LOAD_PAYLOAD<br>
>> > to build MRF payloads.  We do on pre-GEN6.<br>
>> ><br>
>> I'm aware, but you don't need any of this meta-data to LOAD_PAYLOAD<br>
>> *into* an MRF, and LOAD_PAYLOAD with an MRF as source should be illegal<br>
>> anyway.<br>
>><br>
><br>
> And no one is using it that way.  All of the metadata checks you are<br>
> deleting are checks on the *destination*.<br>
><br>
<br>
</div></div>Didn't you write this code yourself?  The only use for the collected<br>
metadata is initializing the instruction flags of the MOVs subsequent<br>
LOAD_PAYLOAD instructions are lowered to, based on the metadata already<br>
collected for its source registers, which can never be MRFs, so the<br>
metadata you collect from MRF writes is never actually used.<br></blockquote><div><br></div><div>Right... I misred something initially.  Yes, we should never be tracking MRF's as a source of a LOAD_PAYLOAD.  I'll give it a better look a bit later, but it looks better. <br></div></div></div></div>