This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH][RS6000] Fix PR87870: ppc64 generates poor code when loading constants into TImode vars
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: Peter Bergner <bergner at linux dot ibm dot com>
- Cc: Michael Meissner <meissner at linux dot ibm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 17 Dec 2018 15:55:06 -0600
- Subject: Re: [PATCH][RS6000] Fix PR87870: ppc64 generates poor code when loading constants into TImode vars
- References: <email@example.com> <20181116170632.GI23873@gate.crashing.org> <firstname.lastname@example.org> <20181116232940.GP23873@gate.crashing.org> <email@example.com> <20181215022338.GQ3803@gate.crashing.org> <firstname.lastname@example.org>
On Mon, Dec 17, 2018 at 02:23:54PM -0600, Peter Bergner wrote:
> On 12/14/18 8:23 PM, Segher Boessenkool wrote:
> > On Thu, Dec 13, 2018 at 10:59:36AM -0600, Peter Bergner wrote:
> >> For the alternatives
> >> I'm changing, we're loading into GPR regs and these alternatives are always
> >> split (split2), so these length values are never used/seen at final assembly
> >> time.
> > But some move instructions are created *after* split2.
> That may be so, but I do not know how we could create a move insn using
> this alternative, since rs6000_output_move_128bit() does the following
> for this alternative (ie, loading a constant into a GPR):
> /* Constants. */
> else if (dest_regno >= 0
> && (GET_CODE (src) == CONST_INT
> || GET_CODE (src) == CONST_WIDE_INT
> || GET_CODE (src) == CONST_DOUBLE
> || GET_CODE (src) == CONST_VECTOR))
> if (dest_gpr_p)
> return "#";
> This means we require the insn to eventually be split and not reach final
> assembly, does it not?
Yes, but is the length attribute used for something that matters before
that? For correctness, not just for better code. It isn't clear to me
that this will work.
OTOH I cannot currently show it does not work either. So, okay for trunk,
and I hope it actually works :-)