[Bug target/67211] [5 Regression] ICE (insn does not satisfy its constraints) on powerpc64le-linux-gnu

[meissner at gcc dot gnu.org]

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

--- Comment #8 from Michael Meissner <meissner at gcc dot gnu.org> ---
A preliminary analysis is -mefficient-unaligned-vector is set in
rs6000_option_override_internal if -mtune=power8 is used. Note, this code uses
a variable 'rs6000_cpu' to indicate the tuning cpu, not the target cpu. Now,
long term we probably should audit the uses of rs6000_cpu to see if they are
related to tuning or arch, and possibly add rs6000_tune for those conditions.

Setting efficient unaligned vector is wrong for a tuning option. I believe the
best approach is to make -mefficient-unaligned-vector a normal masked option in
rs6000_isa. This will allow future processors to specify this option, rather
than going through the code to find (rs6000_cpu == PROCESSOR_POWER8) and adjust
it.

The reason unaligned fast vector support enables the bug is it enables the
option to convert adjacent DImode structure mode members into V2DImode. The
code builds V2DImode vectors in the VSX registers to copy the structure. At the
end of the function, there is a reference to one of the elements, and reload is
trying to combine this with the previous load. But it doesn't have a move
direct operation on a power7 cpu.

The code for power8 looks like:
        lfd 31,320(1)
        ...
        mtvsrd 12,9
        ...
        xxpermdi 63,12,31,0
        stxvd2x 63,1,26
        ...
        mfvsrd 9,31
        addi 9,9,8
        ld 10,0(9)
.LVL14:
        mtvsrd 31,9
.LVL15:
        .loc 1 24 0
        add 9,10,21

In this case, it probably doesn't win to aggregate the structure members as
V2DImode, since it involves a lot of moves and xxpermdi's.

I haven't tracked down why it doesn't fail on trunk compared to the GCC 5
branch.