RFA: Fix PR 22445

[Joern RENNECKE]

Richard Henderson wrote:

>On Wed, Jul 13, 2005 at 01:02:14PM +0100, Joern RENNECKE wrote:
>  
>
>>  	case 'e':
>>+ 	  if (i > 0 && fmt[i-1] == 'e'
>>+ 	      && targetm.commutative_p (x, UNKNOWN)
>>+ 	      && rtx_equal_for_cselib_p (XEXP (x, i), XEXP (y, i-1))
>>+ 	      && rtx_equal_for_cselib_p (XEXP (x, i-1), XEXP (y, i)))
>>    
>>
>
>Do you actually need the fmt[i-1] == 'e' check, given that
>targetm.commutative_p should never return true for a code
>that isn't actually fmt="ee" ?
>  
>
Indeed, from a correctness standpoint, it is not needed.  The rtl concept of
commutativity is much narrower (it applies to binary operations only) 
than the
constraints / md one (you can specify for any pair of consecutive 
operands that
they may be interchanged, and there might be other unrelated operands around
too).
I thought it was still a sensible quick-to-do test to avoid the 
targetm.commutative_p
call, but that doesn't hold up under closer scrutiny:

bash-2.05b$ grep '"[^"]*"[^"]*"[^"]*[^e"]e[^"]*"' rtl.def
DEF_RTL_EXPR(INSN_LIST, "insn_list", "ue", RTX_EXTRA)
DEF_RTL_EXPR(INSN, "insn", "iuuBieiee", RTX_INSN)
DEF_RTL_EXPR(JUMP_INSN, "jump_insn", "iuuBieiee0", RTX_INSN)
DEF_RTL_EXPR(CALL_INSN, "call_insn", "iuuBieieee", RTX_INSN)
DEF_RTL_EXPR(ADDR_DIFF_VEC, "addr_diff_vec", "eEee0", RTX_EXTRA)
DEF_RTL_EXPR(VAR_LOCATION, "var_location", "te", RTX_EXTRA)
DEF_RTL_EXPR(DEFINE_PREDICATE, "define_predicate", "ses", RTX_EXTRA)
DEF_RTL_EXPR(DEFINE_SPECIAL_PREDICATE, "define_special_predicate", 
"ses", RTX_EXTRA)
DEF_RTL_EXPR(DEFINE_INSN_RESERVATION, "define_insn_reservation", "sies", 
RTX_EXTRA)
DEF_RTL_EXPR(DEFINE_ATTR, "define_attr", "sse", RTX_EXTRA)
   (set_attr "name" "value") is equivalent to
   (set (attr "name") (const_string "value"))  */
   (set (attr "att") (cond [(eq_attrq "alternative" "1") (const_string "a1")
DEF_RTL_EXPR(COND, "cond", "Ee", RTX_EXTRA)

When we know that commutative rtl operations are always of "ee" type, 
the only
value the variable "i" can have for a match is 1, and a successful match 
of both
operands implies a successful match of the entire operation.

I have appended an updated patch, which I am re-testing in the 
sh-elf-4_1-branch.

To do mainline testing, I still need a resulution to PR 22258 (The 
latest patch is still
at http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00053.html,  
regtest/bootstrap
has finished successfully long since.)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: tmp
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20050713/d183c58c/attachment.ksh>