This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [TESTCASE] AltiVec code uses wrong rtl expression
- From: Daniel Berlin <dan at dberlin dot org>
- To: Graham Stott <grahams at redhat dot com>
- Cc: Daniel Egger <degger at fhm dot edu>, Aldy Hernandez <aldyh at redhat dot com>, GCC Developer Mailinglist <gcc at gcc dot gnu dot org>
- Date: Mon, 25 Feb 2002 18:42:10 -0500 (EST)
- Subject: Re: [TESTCASE] AltiVec code uses wrong rtl expression
On Mon, 25 Feb 2002, Graham Stott wrote:
> Daniel Egger wrote:
> >
> > Hija,
> >
> > I extended the last testcase a bit to figure out where the code
> > is miscompiled and it turns out that gcc compiles all vec_mergel
> > into vmrghh instead of vmrglh. I checked altivec.h as well as
> > rs6000.[ch] but couldn't find the culprit; in altivec.h the correct
> > builtin is substitued and in rs6000.[ch] is at least no obvious
> > typo so it's probably somewhere deeper but I've not the slightest idea
> > where as the rtl output isn't really clear to me.
> >
>
> It's generating vmrghh because the rtl patterns for altivec_vmrghh and
> altivec_vrmghl are identical and so when it comes to match the generated
> rtl against the md patterns it will always pick the 1st one in the md file
> which is altivec_vmrghh.
They shouldn't be identical
vmrghh = vector merge high
vmrglh = vector merge low
They should be selecting from opposite ends of the input.
>
> If the patterns are correct then they probably need unspecs added so the
> correct pattern gets matched. This is probably true of the other vmrglX/
> vmrghX patterns.
>
> Graham
>