Matt Turner <matts...@gmail.com> writes: > An future commit will enable CSE for CMP instructions. It operates on > the following code > > cmp.ge.f0(8) null g45<8,8,1>F 0F > (+f0) sel(8) g50<1>F g40<8,8,1>F g10<8,8,1>F > cmp.ge.f0(8) null g45<8,8,1>F 0F > (+f0) sel(8) g51<1>F g41<8,8,1>F g11<8,8,1>F > cmp.ge.f0(8) null g45<8,8,1>F 0F > (+f0) sel(8) g52<1>F g42<8,8,1>F g12<8,8,1>F > cmp.ge.f0(8) null g45<8,8,1>F 0F > (+f0) sel(8) g53<1>F g43<8,8,1>F g13<8,8,1>F > > by adding a new cmp.ge.f0(8) instruction writing into a GRF destination > and replacing the existing compares with MOVs from that destination, > leading to: > > cmp.ge.f0(8) g30<1>F g45<8,8,1>F 0F > mov(8) null g30<1>F > (+f0) sel(8) g50<1>F g40<8,8,1>F g10<8,8,1>F > mov(8) null g30<1>F > (+f0) sel(8) g51<1>F g41<8,8,1>F g11<8,8,1>F > mov(8) null g30<1>F > (+f0) sel(8) g52<1>F g42<8,8,1>F g12<8,8,1>F > mov(8) null g30<1>F > (+f0) sel(8) g53<1>F g43<8,8,1>F g13<8,8,1>F > > The next patch will enable dead code elimination of MOVs with a null > destination, which in turn would cause the pass to recognize that the > new compare's g30 destination is never read and delete the instruction. > This would leave the flag register in an unknown state and break the > program.
I think we should just not generate the dead MOVs, instead. It would just be a matter of checking for dst.file == GRF when generating the temporary, right?
pgpTxXkiCDqva.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
