On 05/18/16 23:42, Cesar Philippidis wrote:
+(define_expand "sincossf3" + [(set (match_operand:SF 0 "nvptx_register_operand" "=R") + (unspec:SF [(match_operand:SF 2 "nvptx_register_operand" "R")] + UNSPEC_COS)) + (set (match_operand:SF 1 "nvptx_register_operand" "=R") + (unspec:SF [(match_dup 2)] UNSPEC_SIN))] + "flag_unsafe_math_optimizations" +{ + emit_insn (gen_sinsf2 (operands[1], operands[2])); + emit_insn (gen_cossf2 (operands[0], operands[2])); + + DONE; +})Why the emit_insn code? that seems to be replicating the RTL representation -- you're saying the same thing twice.
You've not answered this. I always find it confusing when insn expansions say the same thing in the RTL represntation as the C fragment is generating.
My intent was to verify that I got the sin and cos arguments right, i.e., make sure that this sincos expansion didn't mix up sin(x) with cos(x). I guess I can create a test that uses vprintf and scans
That's a good idea, but I think you need a much clearer testcase. It'd be better to check both the sin and cos outputs (and, that's going to be 'interesting' making sure only one path gets to be seen by the sincos optimizer -- but not difficult.
nathan
