[PATCH, WIP] NEON quadword vectors in big-endian mode (#10061, #7306)
ira.rosen at linaro.org
Tue Nov 30 10:25:18 UTC 2010
On 22 November 2010 13:46, Ira Rosen <ira.rosen at linaro.org> wrote:
> On 17 November 2010 13:21, Julian Brown <julian at codesourcery.com> wrote:
>>> > We'd need to figure out what the RTL for such loads/stores should
>>> > look like, and whether it can represent alignment constraints, or
>>> > strides, or loads/stores of multiple vector registers simulateously.
> Alignment info is kept in struct ptr_info_def.
> Is it necessary to represent stride?
> Multiple loads/stores seem the most complicated part to me. In neon.md
> vld is implemented with output_asm_insn. Is it going to change? Does
> this assure consecutive (or stride two) registers?
>>> > Getting it right might be a bit awkward, especially if we want to
>>> > consider a scope wider than just NEON, i.e. other vector
>>> > architectures also.
>>> I think we need to somehow enhance MEM_REF, or maybe generate a
>>> MEM_REF for the first vector and a builtin after it.
>> Yeah, keeping these things looking like memory references to most of
>> the compiler seems like a good plan.
> Is it possible to have a list of MEM_REFs and a builtin after them:
> v0 = MEM_REF (addr)
> v1 = MEM_REF (addr + 8B)
> v2 = MEM_REF (addr + 16B)
> builtin (v0, v1, v2, stride=3, reg_stride=1,...)
> to be expanded into:
> <regular RTL mem refs> (addr)
> NOTE (...)
I guess we can do something similar to load_multiple here (but it
probably requires changes in neon.md as well).
> and then combined into vld3?
More information about the linaro-toolchain