[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