This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH], Fix V1TI in Altivec regs on old systems
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: Michael Meissner <meissner at linux dot ibm dot com>, gcc-patches at gcc dot gnu dot org, dje dot gcc at gmail dot com
- Date: Thu, 29 Aug 2019 12:02:05 -0500
- Subject: Re: [PATCH], Fix V1TI in Altivec regs on old systems
- References: <20190820180031.GA23728@ibm-toto.the-meissners.org>
On Tue, Aug 20, 2019 at 02:00:31PM -0400, Michael Meissner wrote:
> noticed on power5 that the V1TImode mode is allowed in Altivec registers, even
> though power5 doesn't have Altivec registers.
> While it doesn't seem to effect anything (I couldn't create a test case that
> failed), it is a small nit that should be fixed. The test for TARGET_VADDUQM
> matches a test earlier in the function where VSX registers are checked.
Yeah, but does that test make any sense?
Why p8 (or later) only? Why vector only? (Well that one is clear, and
what this patch is about). Why -mpowerpc64 only? Because it has __int128
maybe? But then you should test for *that* (and why is it important?)
Where would V1TI go if not in vector regs? Just in memory?
And, what happens on 970? p5 doesn't have vector registers, but 970 does.
> --- gcc/config/rs6000/rs6000.c (revision 274635)
> +++ gcc/config/rs6000/rs6000.c (working copy)
> @@ -1874,7 +1874,7 @@ rs6000_hard_regno_mode_ok_uncached (int
> /* AltiVec only in AldyVec registers. */
> if (ALTIVEC_REGNO_P (regno))
> return (VECTOR_MEM_ALTIVEC_OR_VSX_P (mode)
> - || mode == V1TImode);
> + || (TARGET_VADDUQM && mode == V1TImode));