This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] PR target/41210 -- Fix ICE with vsx_movv2df


On Thu, Sep 10, 2009 at 03:50:00PM -0400, David Edelsohn wrote:
> On Wed, Sep 9, 2009 at 6:54 PM, Michael Meissner
> <meissner@linux.vnet.ibm.com> wrote:
> > This patch fixes the code gen problem highlighted in PR target/41210, where the
> > compiler was trying to load up a vector register into GPRs using reg+reg
> > addressing.
> >
> > I have done a bootstrap/make check with this patch, and there were no
> > regressions. ?The test gcc.target/powerpc/vsx-builtin-7.c now works with this
> > patch. ?Is it ok to apply to the mainline?
> >
> > 2009-09-09 ?Michael Meissner ?<meissner@linux.vnet.ibm.com>
> >
> > ? ? ? ?PR target/41210
> > ? ? ? ?* config/rs6000/vsx.md (vsx_mov<mode>): Use 'Q' for moves of
> > ? ? ? ?vector types to/from GPR registers to restrict the address to be a
> > ? ? ? ?single register instead of register+register.
> > ? ? ? ?* config/rs6000/altivec.md (altivec_mov<mode>): Ditto.
> 
> Mike,
> 
> I think some of the explanation in the ChangeLog should be in the
> comment about 'Q' in the pattern, e.g., offset addresses are not
> valid.  I think you are saying that although a constraint allowing
> offset addressing (that does not overflow the offset) would be valid,
> Altivec and VSX modes do not allow offset addressing, so a constraint
> for an indirect address achieves the same effect.
> 
> If I understand you correctly, the patch is okay with that clarification.

Actually, your question caused me to dig deeper (thanks), and it turns out it
was picking a GPR, not because of some reload issue (which the symptom I was
trying to patch), but instead because I evidently missed a sutble detail to
allow vector double functions to return the argument in a VSX/Altivec register,
and instead it was trying to return the value in a GPR register.

So, this is only a VSX issue, and the altivec was a red-herring.

The code in question is:
vector double insert_sf_n (vector double p, double x, int n) { return vec_insert (x, p, n); }

If I change this to not return a vector double, it works fine.

-- 
Michael Meissner, IBM
4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
meissner@linux.vnet.ibm.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]