On Tue, Oct 22, 2013 at 1:56 PM, Eric Anholt <e...@anholt.net> wrote: > 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?
Yes, I think so. I like that plan better, because I've heard something about null MOVs being necessary for workarounds on gen4 or similar. I'll send a new patch to replace this one and a revised commit message for 4/7. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
