[Mesa-dev] [PATCH 1/2] i965: Combine some dead code elimination NOP'ing code.

Francisco Jerez currojerez at riseup.net
Tue Jan 17 18:35:46 UTC 2017


Kenneth Graunke <kenneth at whitecape.org> writes:

> On Saturday, January 14, 2017 11:09:53 PM PST Francisco Jerez wrote:
>> Hi Ken!
>> 
>> Kenneth Graunke <kenneth at whitecape.org> writes:
>> 
>> > In theory we might have incorrectly NOP'd instructions that write the
>> > flag, but where that flag value isn't used, and yet the instruction
>> > either writes the accumulator or has side effects.
>> >
>> > I don't believe any such instructions exist, so this is mostly a
>> > code cleanup.
>> >
>> One example that occurred to me: The FB write opcode writes the flag
>> register (on Gen4-5 due to the dynamic AA payload hack), its flag result
>> is invariably dead (because the flag result is only ever used internally
>> to decide whether to send AA data or not), and has obvious side effects.
>> 
>> I believe the only reason why the code below wouldn't incorrectly nop
>> out FB writes is because of another, also somewhat concerning bug --
>> backend_instruction::flags_written() is completely unaware of FB writes
>> modifying the flag register on Gen4-5, which led to actual corruption in
>> my SIMD32 branch (I have a somewhat half-baked patch to fix it but I
>> think we should probably land this first).
>
> Oh, interesting!  I forgot about that case.  I could see that being a
> problem - if there were multiple FB writes (either split up, or MRT),
> scheduling might move things around badly.  Presumably the fact that
> they use the same MRFs ends up saving us from that, today.
>

I doubt MRFs would prevent the scheduler from moving a flag-consuming
operation past the FB write.

> Sounds like this is a worthwhile fix, and we'll need your other ones
> as well :)
>
>> > Signed-off-by: Kenneth Graunke <kenneth at whitecape.org>
>> > ---
>> >  src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp | 8 +-------
>> >  1 file changed, 1 insertion(+), 7 deletions(-)
>> >
>> > diff --git a/src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp b/src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp
>> > index 8a0469a51b9..930dc733b45 100644
>> > --- a/src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp
>> > +++ b/src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp
>> > @@ -70,17 +70,11 @@ fs_visitor::dead_code_eliminate()
>> >              }
>> >           }
>> >  
>> > -         if (inst->dst.is_null() && inst->flags_written()) {
>> > -            if (!(flag_live[0] & inst->flags_written())) {
>> > -               inst->opcode = BRW_OPCODE_NOP;
>> > -               progress = true;
>> > -            }
>> > -         }
>> > -
>> >           if ((inst->opcode != BRW_OPCODE_IF &&
>> >                inst->opcode != BRW_OPCODE_WHILE) &&
>> >               inst->dst.is_null() &&
>> >               !inst->has_side_effects() &&
>> > +             !(flag_live[0] & inst->flags_written()) &&
>> 
>> I don't think this will have the intended effect unless you remove the
>> line below in addition, otherwise instructions that write a flag result
>> which happens to be dead will never get nop'ed out.
>
> Whoops :)  I meant to delete that.  (You can see that it's gone in the
> next patch, where I refactored this into a helper function...)  I've
> fixed that locally.  Thanks!
>

Heh, fair enough.  With that fixed [and the comment in the commit
message saying that this is only a code cleanup ;)] patch is:

Reviewed-by: Francisco Jerez <currojerez at riseup.net>

>> 
>> >               !inst->flags_written() &&
>> >               !inst->writes_accumulator) {
>> >              inst->opcode = BRW_OPCODE_NOP;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 212 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170117/aa83b610/attachment.sig>


More information about the mesa-dev mailing list