Committed: fix 4.3-branch regressions appearing with r135124

[Hans-Peter Nilsson]

With r135124 (compared to r135123) on the 4.3 branch, I see
three regressions:

gcc.sum gcc.dg/sms-3.c
gcc.sum gcc.dg/var-expand2.c
gfortran.sum gfortran.dg/anyallcount_1.f90

they're all ICE's that look in the .log like:
/tmp/hpautotest-gcc43/gcc/gcc/testsuite/gcc.dg/sms-3.c: In function 'foo':
/tmp/hpautotest-gcc43/gcc/gcc/testsuite/gcc.dg/sms-3.c:24: internal compiler error: in cris_address_cost, at config/cris/cris.c:1887

which in turn are due to the same non-canonical rtx as in
<http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00623.html>
reaching this code (see also PR35867 and of course PR28690).

At first I thought Steve had missed to actually back out the
rtlanal.c bits, but that theory was easily proved wrong and I
don't see anything in 135124 on the 4.3 branch that is obvious
in why it'd change canonicalization anywhere.  But, a gdb
session shows that it's just fwprop2 checking whether a register
can be profitably replaced in a PLUS of two registers, where
those registers are now swapped, due to one properly being
marked as a pointer.  So, it seems like a hidden bug uncovered
by 135124 that could probably just as well appear for other code
before this change.  Again, GO_IF_LEGITIMATE_ADDRESS has said
the noncanonical adress is valid, so it's just cris_address_cost
(targetm.address_cost) that inconsistently doesn't handle it.

Perhaps it could be seen as a missed rtx canonicalization call,
but adding a canonicalization call on the branch seems more
risky than importing a valid target-specific fix.  Indeed the
same change as in the gcc-patches URL above is the solution,
hence committed as 135195 (not repeated here).

brgds, H-P