On Fri, Mar 13, 2015 at 4:16 PM, Kenneth Graunke <kenn...@whitecape.org> wrote: > Commit 36bc5f06dd22 began allowing immediates in MAD and LRP sources, > in any position. One unforeseen consequence is that opt_algebraic began > creating ADD and MUL instructions with src0 immediates. > > For example, > > mad(8) vgrf86:F, 1.000000f, 1.000000f, vgrf84:F > > would be optimized into: > > add(8) vgrf86:F, 1.000000f, vgrf84:F > > which is illegal. > > Fixes assert failures in steam/tiny-and-big-grandpas-leftovers/fp-19. > > Signed-off-by: Kenneth Graunke <kenn...@whitecape.org> > ---
We've talked about wanting to remove some hardware restrictions from the IR like this, and I think if we have a good reason to do that then this is a good way to do it. But currently the only source of this problem comes from 13 lines of code in opt_algebraic. Fixing the problem at the source makes a lot of sense to me. What advantage of this series do you see over that? Maybe the conversation should be about how allowing immediates in other sources would allow some additional optimization -- for instance we don't do proper constant folding because of this restriction. I'd be interesting to see if we could find some cases that benefit from that. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
