[PING][PATCH, rs6000] Fix PR target/42427

[David Edelsohn]

On Tue, Mar 16, 2010 at 1:03 PM, Peter Bergner <bergner@vnet.ibm.com> wrote:

> Ok, here's an updated patch that extends rs6000_split_multireg_move() which
> greatly simplifies the movdf_{hard,soft}float32 patterns.  In addition,
> I noticed that the movdd_{hard,soft}float32 pattern contains the same
> bug so I fixed it too, even though I was never able to trigger it.
> Since we already have a movdi splitter which calls r_s_m_m(), I just
> created a mode iterator and used that to create a common splitter
> for movdi, movdf and movdd.
>
> To give the patch a good workout, I bootstrapped the following patch
> with powerpc-linux and powerpc64-linux bootstraps.  I then ran the
> testsuite in the powerpc64-linux build in both -m32 and -m64 modes
> with no regressions.  As an extra test, I also bootstrapped and
> regtested the patch with the two hunks:
>
>    if (TARGET_UPDATE && optimize_size)
> changed to:
>    if (1 || (TARGET_UPDATE && optimize_size))
> to give that code an extra working over.  Again, no regressions.
>
> Is this ok for mainline?

>
> gcc/
>        PR target/42427
>        * config/rs6000/rs6000.c (rs6000_split_multireg_move):
>        * config/rs6000/dfp.md (*movdd_hardfloat32): Make the "0", "1"
>        and "2" alternatives "#".
>        (*movdd_softfloat32): Make all alternatives "#";
>        * config/rs6000/rs6000.md (DIFD): New define_mode_iterator.
>        (*movdf_hardfloat32): Make the "0", "1" and "2" alternatives "#".
>        (*movdf_softfloat32): Make all alternatives "#";
>        (movdi): Use the new DIFD mode iterator to create a common splitter
>        for movdi, movdf and movdd patterns.
>
> gcc/testsuite/
>        PR target/42427
>        * gcc.dg/pr42427.c: New test.

Peter,

The ChangeLog entry for the rs6000.c rs6000_split_multireg_move change is empty.

Also, please remove "&& optimize_size".  There should be an
abstraction separating the policy from the optimization.  We want the
policy centralized, not scattered around the machine description to
avoid future maintenance problems and apply the appropriate
granularity.  If we want to conditionally set MASK_NO_UPDATE in
target_flags for recent POWER processors when not optimizing for size,
we should enable that separately and uniformly in
rs6000_override_options.

Thanks, David