On Fri, Mar 24, 2017 at 07:16:32PM -0500, Segher Boessenkool wrote:
> Hi Mike,
>
> This patch is okay for trunk. Also for 6, but what is the hurry there?
I applied the patch (svn id 246508 for trunk, svn id 246509 for gcc 6.0). The
hurry up for GCC 6 is due to the fact that the bug does not sho
On Fri, Mar 24, 2017 at 07:16:32PM -0500, Segher Boessenkool wrote:
> Hi Mike,
>
> On Fri, Mar 24, 2017 at 07:23:02PM -0400, Michael Meissner wrote:
> > Reload fumbles in certain conditions.
>
> Yeah. And it does not need bswap to get totally lost with this, so this
> patch is a workaround, not
Hi Mike,
On Fri, Mar 24, 2017 at 07:23:02PM -0400, Michael Meissner wrote:
> Reload fumbles in certain conditions.
Yeah. And it does not need bswap to get totally lost with this, so this
patch is a workaround, not a fix.
It does make things nicer though :-)
> LRA generates working code, but th
Well instead of attaching the ChangeLog, I attached the patch without
ChangeLog.
Here is the ChangeLog entry for the patch:
[gcc]
2017-03-24 Michael Meissner
PR target/78543
* config/rs6000/rs6000.md (BSWAP): New mode iterator for modes
with hardware byte swap load/sto
This patch reworks the original patch I attached to the bug report, to try and
make it less hacky. It separates the bswap insns where there is hardware
support into separate read, write, and register swap instructions. This is
because the register allocators will try to push the bswap value in a r