On 11/01/2016 03:39 PM, Wilco Dijkstra wrote:
Jeff Law wrote:
I think you'll need to look at bz61320 before this could go in.
I had a look, but there is nothing there that is related - eventually
a latent alignment bug was fixed in IVOpt.
Excellent. Thanks for digging into what really hap
On Wed, Nov 2, 2016 at 2:43 PM, Wilco Dijkstra wrote:
> Richard Biener wrote:
> On Tue, Nov 1, 2016 at 10:39 PM, Wilco Dijkstra
> wrote:
>
>> > If bswap is false no byte swap is needed, so we found a native endian load
>> > and it will always perform the optimization by inserting an unaligned lo
Richard Biener wrote:
On Tue, Nov 1, 2016 at 10:39 PM, Wilco Dijkstra wrote:
> > If bswap is false no byte swap is needed, so we found a native endian load
> > and it will always perform the optimization by inserting an unaligned load.
>
> Yes, the general agreement is that the expander can do be
On Tue, Nov 1, 2016 at 10:39 PM, Wilco Dijkstra wrote:
> Jeff Law wrote:
>
>> I think you'll need to look at bz61320 before this could go in.
>
> I had a look, but there is nothing there that is related - eventually
> a latent alignment bug was fixed in IVOpt. Note that the bswap phase
> current
Jeff Law wrote:
> I think you'll need to look at bz61320 before this could go in.
I had a look, but there is nothing there that is related - eventually
a latent alignment bug was fixed in IVOpt. Note that the bswap phase
currently inserts unaligned accesses irrespectively of STRICT_ALIGNMENT
or
On 11/01/2016 11:36 AM, Wilco Dijkstra wrote:
Looking at PR77308, one of the issues is that the bswap optimization
phase doesn't work on ARM. This is due to an odd check that uses
SLOW_UNALIGNED_ACCESS (which is always true on ARM). Since the testcase
in PR77308 generates much better code with
