[PATCH] AArch64: big endian constant vector pools

Christian Pirker cpirker at a-bix.com
Mon Apr 14 11:36:01 PDT 2014


Hi Tim,

your solution looks good to me.
I will try it as the next step.

Thanks,
Christian

On 04/14/14 12:22, Tim Northover wrote:
>> 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