On Wed, Nov 14, 2012 at 1:51 PM, Andrew Pinski wrote: > On Wed, Nov 14, 2012 at 1:45 PM, Steve Ellcey wrote: >> On Wed, 2012-11-14 at 12:00 -0800, Andrew Pinski wrote: >> >>> I know exactly where this code comes from; I have looked at the >>> benchmark as one of the reason why I add expand_cond_expr_using_cmove >>> in the first place. Anyways you should look into removing >>> TARGET_PROMOTE_PROTOTYPES because I found that also fixes the problem >>> mentioned here. >>> >>> Thanks, >>> Andrew Pinski >> >> Removing TARGET_PROMOTE_PROTOTYPES looks interesting but I don't know if >> it is possible for compatibility reasons. I am still looking at my >> example though, I see GCC doing: >> >> andi $5,$5,0x1 >> xori $5,$5,0x1 >> movz $2,$4,$5 >> >> When it should just do: >> >> andi $5,$5,0x1 >> movn $2,$4,$5 > > Yes I have a few patches for improving this case. I have not > submitted them yet though. > Attached is the assembly I get from a 4.7 toolchain with all of the > changes I have internally applied; this is for n32 (though o32 > produces the exact same code in this case). I will try to post some > more in the next coming weeks. Removing Richard B. from the CC list since this is now a MIPS specific change (the original patch is still needed though). Here is the patch which should improve the above case. I have not tested it on the trunk yet but it applies there. Basically the *mov_on__ne pattern is the one which is needed in this case. The other two changes are done for 64bit comparisons. Thanks, Andrew Pinski > > Thanks, > Andrew Pinski > > >> >> >> Steve Ellcey >> sellcey@mips.com >> >>