[patch, mips] Fix optimization bug involving nor instruction

2013-10-22 Thread Steve Ellcey
While looking at some MIPS code I found that GCC was not making optimal use of the MIPS nor instruction. If you compile this function: int f (int a, int b) { return ~(a|b); } It generates: or $2,$4,$5 nor $2,$0,$2 instead of just: nor $2,$4,$5

Re: [patch, mips] Fix optimization bug involving nor instruction

2013-10-22 Thread Richard Sandiford
Good spot! Steve Ellcey sell...@mips.com writes: diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c index 5993aab..ffb0b53 100644 --- a/gcc/config/mips/mips.c +++ b/gcc/config/mips/mips.c @@ -3796,6 +3796,18 @@ mips_rtx_costs (rtx x, int code, int outer_code, int opno

Re: [patch, mips] Fix optimization bug involving nor instruction

2013-10-22 Thread Steve Ellcey
On Tue, 2013-10-22 at 18:34 +0100, Richard Sandiford wrote: Good spot! We should use set_src_cost for both operands (the idea being that only a register is allowed, and that anything else will end up being a SET_SRC). I think the formatting should be something like: /* (AND (NOT op0)

Re: [patch, mips] Fix optimization bug involving nor instruction

2013-10-22 Thread Richard Sandiford
Steve Ellcey sell...@mips.com writes: On Tue, 2013-10-22 at 18:34 +0100, Richard Sandiford wrote: Good spot! We should use set_src_cost for both operands (the idea being that only a register is allowed, and that anything else will end up being a SET_SRC). I think the formatting should be

Re: [patch, mips] Fix optimization bug involving nor instruction

2013-10-22 Thread Steve Ellcey
On Tue, 2013-10-22 at 19:12 +0100, Richard Sandiford wrote: Richard OK, but I am curious why you put parenthesis around the right hand side of the total expression. I.e. *total = (); That's the emacs formatting rule: OK, I have checked in the patch with the parenthesis (and your