This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Clean up MIPS branch handling, fix mips-ps-*.c failures
Richard Sandiford writes:
> So the change on its own was a net loss for you?
To be precise this is the change I had in my tree:
Index: config/mips/mips.c
===================================================================
--- config/mips/mips.c (revision 111703)
+++ config/mips/mips.c (working copy)
@@ -3193,7 +3193,7 @@ gen_conditional_branch (rtx *operands, e
mips_emit_compare (&code, &op0, &op1, TARGET_MIPS16);
target = gen_rtx_IF_THEN_ELSE (VOIDmode,
- gen_rtx_fmt_ee (code, GET_MODE (op0),
+ gen_rtx_fmt_ee (code, GET_MODE (op0) == CCmode? CCmode : VOIDmode,
op0, op1),
gen_rtx_LABEL_REF (VOIDmode, operands[0]),
pc_rtx);
And I was getting this diffstat on assembly generated from
GCC preprocessed files:
39 files changed, 8229 insertions(+), 8118 deletions(-)
After I removed the early return in simplify_relational_operation for
mode == VOIDmode I am still down but less:
10 files changed, 192 insertions(+), 185 deletions(-)
The remaining pessimizations have this form:
- bgez $2,$L4068
+ dsrl $2,$2,63
+ sll $2,$2,0
+ beq $2,$0,$L4068
I was trying to come up with a small testcase for this yesterday but I
couldn't. I will look into it more later today. Also note that the
truncation is in the way of recognizing that this is just a branch on
the sign-bit. My patch to expose truncates to the middle-end should
eliminate the truncation here but I guess it is still better to
understand the issue as it is.
Adam