On Sat, Mar 4, 2017 at 9:21 PM, Francisco Jerez <curroje...@riseup.net> wrote: > Ilia Mirkin <imir...@alum.mit.edu> writes: > >> Also, how is this happening in the first place? For example, we have: >> >> case ir_unop_bitcast_f2i: >> case ir_unop_bitcast_f2u: >> /* Make sure we don't propagate the negate modifier to integer >> opcodes. */ >> if (op[0].negate || op[0].abs) >> emit_asm(ir, TGSI_OPCODE_MOV, result_dst, op[0]); >> else >> result_src = op[0]; >> >> Oh, but it's going directly into a ir_triop_csel, which is missing >> this logic. It should be added there instead, IMHO. OTOH, the same >> issue will hit in emit_block_mov() if you do. Would love to hear some >> other opinions... Marek, Brian, Roland? >> > > I considered doing something like that but it will be somewhat more > involved than in the snippet above because you'll have to allocate > temporaries to hold the negated source results in case that any of the > csel sources has a modifier set -- Can look into it next week if you > think it's the right thing to do.
Right, that's mildly annoying but definitely solvable. One last thought from me - for ir_unop_abs, we do the MOV. So perhaps we should just suck it up and do the MOV here. But I'd really like to hear from others. -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
