On 11/01/2016 03:39 PM, Wilco Dijkstra wrote:
Jeff Law <l...@redhat.com> 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 happened.
Note that the bswap phase
currently inserts unaligned accesses irrespectively of STRICT_ALIGNMENT
or SLOW_UNALIGNED_ACCESS:
- if (bswap
- && align < GET_MODE_ALIGNMENT (TYPE_MODE (load_type))
- && SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align))
- return false;
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.
This apparently works on all targets, and doesn't cause alignment traps or
huge slowdowns via trap emulation claimed by SLOW_UNALIGNED_ACCESS.
So I'm at a loss what these macros are supposed to mean and how I can query
whether a backend supports fast unaligned access for a particular mode.
What I actually want to write is something like:
if (!FAST_UNALIGNED_LOAD (mode, align)) return false;
And know that it only accepts unaligned accesses that are efficient on the
target.
Maybe we need a new hook like this and get rid of the old one?
As Richi indicated later, these decisions are probably made best at
expansion time -- as long as we have the required information. So I'd
only go with a hook if (for example) the alignment information is lost
by the time we get to expansion and thus we can't DTRT at expansion time.
Patch is OK.
jeff
