On Mon, Sep 23, 2013 at 2:12 PM, Kenneth Graunke <[email protected]> wrote: > emit_bool_to_cond_code() takes separate paths for ir_expressions and.
Sentence ends unexpectedly? > If the argument to emit_bool_to_cond_code() is an ir_expression, we > loop over the operands, calling accept() on each of them, which > generates assembly code to compute that subexpression. We then emit > one or two final instruction that perform the top-level operation on > those operands. > > If it's not an expression (say, a boolean-valued variable), we simply > call accept() on the whole value. > > In commit 80ecb8f1 (i965/fs: Avoid generating extra AND instructions on > bool logic ops), Eric made logic operations jump out of the expression > path to the non-expression path. > > Unfortunately, this meant that we would first accept() the two operands, > skip generating any code that used them, then accept() the whole > expression, generating code for the operands a second time. > > Dead code elimination would always remove the first set of redundant > operand assembly, since nothing actually used them. But we shouldn't > generate it in the first place. > > Signed-off-by: Kenneth Graunke <[email protected]> > Cc: Matt Turner <[email protected]> > Cc: Eric Anholt <[email protected]> > --- Both patches are Reviewed-by: Matt Turner <[email protected]> For posterity, this patch was preventing my addc+add -> addc peephole from working. Thanks for tracking this down. Matt _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
