[PATCH] AArch64: big endian constant vector pools
Tim Northover
t.p.northover at gmail.com
Mon Apr 14 03:22:44 PDT 2014
> The solution you described above implies introducing "rev" for arguments and
> return values passed by VPR at all function boundaries, so wouldn't it cause
> poor performance?
Quite right, and yes that's the major performance regression in the
ld1/st1 solution.
> This is simply because it would make LLVM implementation easier, and I think
> to some extension it's unacceptable.
A view I'm sympathetic to, with limits on just how much clutter I'd
want to add to LLVM for the sake of big-endian. But at the moment it
looks like either way would be tolerable so performance could well be
the deciding factor.
> However, I'm OK to move forward with two steps. Step 1 is to implement the
> simplified solution as you probably proposed, and for step 2 finally we need
> to optimize those unnecessary "rev"s removed.
We can do something about the function-internal ones ones in future,
but I think the only way to get the ABI performance is to rule out the
ld1/st1 solution entirely.
Cheers.
Tim.
More information about the llvm-commits
mailing list