On 17 November 2010 13:21, Julian Brown <jul...@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 (...) and then combined into vld3? Ira _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
