On Thu, 10 May 2012 17:31:43 +0200 Christophe Lyon <christophe.l...@st.com> wrote:
> On 10.05.2012 13:41, Ramana Radhakrishnan wrote: > > On 9 May 2012 11:18, Christophe Lyon<christophe.l...@st.com> wrote: > >> Hello, > >> > >> On ARM+Neon, the expansion of vld1q_dup_s64() and vld1q_dup_u64() > >> builtins currently fails to load the second vector element. > > Thanks for the patch but this is not acceptable as it stands today. > > You need to set the length attributes in this case to 8 for the > > appropriate alternative at the very least. > OK I'll look at this. > > > You also don't mention how this patch was tested. > I used the testsuite I developed some time ago to test all the Neon > builtins, which I posted last year on the qemu mailing-list. With the > current GCCs, this bug is the only remaining one I could detect. > > > Alternatively it might be worth splitting the > > vld1q_*64 case into a 64 bit load into a (subreg:DI (V2DI reg) 0 ) > > followed by a subreg to subreg move which should end up having the > > same effect . That splitting would allow for better instruction > > scheduling. > Are you aware of examples of similar cases I could use as a model? > > > In addition it would be nice to have a testcase in > > gcc.target/arm . > Well. Prior to sending my patch I did look at that directory, but I > supposed that such a test ought to belong to the neon/ subdir where > the tests are described as autogenerated. Any doc on how to do that? I'd recommend not to autogenerate such a test, FWIW -- the autogenerated neon tests aren't very good. I think a manually-written execute test would be better in this case. If you do try autogenerating tests, look at "Disassembles_as" in neon.ml, and neon-testgen.ml. Julian
