[Bug target/65614] New: PowerPC VSX systems should use XSCPSGNDP to copy scalar fp data to/from Altivec registers

meissner at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Fri Mar 27 19:43:00 GMT 2015


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65614

            Bug ID: 65614
           Summary: PowerPC VSX systems should use XSCPSGNDP to copy
                    scalar fp data to/from Altivec registers
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: meissner at gcc dot gnu.org
              Host: powerpc64-unknown-linux-gnu
            Target: powerpc64-unknown-linux-gnu
             Build: powerpc64-unknown-linux-gnu

In trying to run Spec 2006 with the LRA register allocator, some of the
benchmarks hang on power7 (and presumably power8) after my fix for PR 65240
went it.  That fix changed how floating point constants are loaded into memory
and it now uses LFS (load float single precision) to load constants that can be
stored in single precision when -ffast-math is used (previously it only did
this optimization without -ffast-math).

The LRA register allocator is more aggressive about allocating scalar values to
the traditional Altivec registers, and will load constants into the FPR
registers, and do a move to an Altivec register.

Right now, GCC uses an XXLOR instruction to move scalar FP values outside of
the FPR registers.  In some cases, loading a value with LFS will create dirty
data and some instructions will generate a denormal exception if they get a
value with dirty data.

For moves between FPRs, the FMR instruction will convert the dirty data to a
non-dirty double precision value.  If we are moving to/from Altivec registers,
we should use a XSCPSGNDP instruction instead of XXLOR, since XSCPSGNDP is like
FMR in that it cleans up the data.



More information about the Gcc-bugs mailing list