<div dir="ltr"><div><div><div>I'm still a little pensive.  But<br><br></div>Reviewed-by: Jason Ekstrand <<a href="mailto:jason.ekstrand@intel.com">jason.ekstrand@intel.com</a>><br><br></div>Now for a little aside.  I have come to the conclusion that I made a grave mistake when I did the LOAD_PAYLOAD stuff.  In retrospect, I should have just subclassed fs_inst for load_payload.  The problem is that we need to snag a bunch of information for the sources when we create the load_payload.  In particular, we need to know the width of the source so that we know how much space it consumes in the payload and we need to know the information required to properly re-create the mov such as force_sechalf and force_writemask_all.  Really, in order to do things properly, we need to gather this information *before* we do any optimizations.  The nasty pile of code that you're editing together with the "effective_width" parameter is a lame attempt to capture/reconstruct this information.  Really, we should just subclass, capture the information up-front, and do it properly.<br><br></div>--Jason<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 19, 2015 at 1:53 PM, Jason Ekstrand <span dir="ltr"><<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">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><div>Jason Ekstrand <<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>> writes:<br>
<br>
> On Thu, Feb 19, 2015 at 12:13 PM, Francisco Jerez <<a href="mailto:currojerez@riseup.net" target="_blank">currojerez@riseup.net</a>><br>
> wrote:<br>
><br>
>> Jason Ekstrand <<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>> writes:<br>
>><br>
>> > On Fri, Feb 6, 2015 at 4:01 PM, Francisco Jerez <<a href="mailto:currojerez@riseup.net" target="_blank">currojerez@riseup.net</a>><br>
>> > wrote:<br>
>> ><br>
>> >> Hey Matt,<br>
>> >><br>
>> >> Matt Turner <<a href="mailto:mattst88@gmail.com" target="_blank">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" target="_blank">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></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>
</blockquote></div><br></div>