[PATCH, rs6000] Fix PR target/67808, LRA ICE on double to long double conversion

David Edelsohn dje.gcc@gmail.com
Tue Oct 6 14:33:00 GMT 2015


On Mon, Oct 5, 2015 at 6:36 PM, Michael Meissner
<meissner@linux.vnet.ibm.com> wrote:
> Ok, after spending the day on going down the rabbit hole of trying to optimize
> just about every, here are my patches.
>
> Note, I simplified the constraints to eliminate some rare possibilities, like
> optimizing converting from double to long double if the double happened to be
> in a GPR register and the long double value was stored in memory (but there
> never was an optimization for having the double value be in a GPR and the long
> double value to also be a GPR).
>
> I also separated the VSX case from the non-VSX case. This is to simplify things
> at the RTL level (non-VSX must load up 0.0 to put into the lower word, while
> VSX can use the XXLXOR instruction to clear the register).
>
> I dropped support in the insns for extending the DFmode value to TFmode that is
> located in memory directly. Now, the compiler builds the whole value in FPRs
> and then does the store. This simplifies the code somewhat, and SPE/ieeequad
> paths require the value to be in registers, which might lead to other lra
> bugs. In the case of just doing one conversion in straight line code, it just
> changes the register allocation somewhat (allocate 1 TFmode pseudo instead of
> 1-2 DFmode psuedos).
>
> I have bootstrapped the compiler on little endian power8 with no regressions. I
> have built the test case with various options (-mlra vs. no -mlra, 32-bit,
> 64-bit, power5/power6/power7/power8), and it all builds correctly.
>
> Is this patch ok to apply to the trunk?
>
> I would like to apply this patch to GCC 5.x as well. However, in doing the
> patch, this patch touches areas that I've been working on for IEEE 128-bit
> floating point support, and so the patch will need to be reworked for GCC
> 5.x.  Is it ok to install in the trunk?
>
> In addition, I will need to modify this area again with the next IEEE 128-bit
> floating point support patch, but I wanted to separate this patch out so that
> it could be considered by itself, and back ported to GCC 5.x.
>
> [gcc]
> 2015-10-05  Michael Meissner  <meissner@linux.vnet.ibm.com>
>             Peter Bergner  <bergner@vnet.ibm.com>
>
>         PR target/67808
>         * config/rs6000/rs6000.md (extenddftf2): In the expander, only
>         allow registers, but provide insns for the combiner to create for
>         loads from memory. Separate VSX code from non-VSX code. For
>         non-VSX code, combine extenddftf2_fprs into extenddftf2 and rename
>         externaldftf2_internal to externaldftf2_fprs. Reorder constraints
>         so that registers come before memory operations. Drop support from
>         converting DFmode to TFmode, if the DFmode value is in a GPR
>         register, and the TFmode is in memory.
>         (extenddftf2_fprs): Likewise.
>         (extenddftf2_internal): Likewise.
>         (extenddftf2_vsx): Likewise.
>         (extendsftf2): In the expander, only allow registers, but provide
>         insns for the combiner to create for stores and loads.
>
> [gcc/testsuite]
> 2015-10-05  Michael Meissner  <meissner@linux.vnet.ibm.com>
>             Peter Bergner <bergner@vnet.ibm.com>
>
>         PR target/67808
>         * gcc.target/powerpc/pr67808.c: New test.

This is okay for trunk, but can we hold off for GCC 5 and allow things
to settle?

Thanks, David



More information about the Gcc-patches mailing list