On 22 November 2010 13:46, Ira Rosen <ira.ro...@linaro.org> wrote: > 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 (...)
I guess we can do something similar to load_multiple here (but it probably requires changes in neon.md as well). Ira > > and then combined into vld3? > > Ira > _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
