This is the mail archive of the 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][RS6000] Fix PR87870: ppc64 generates poor code when loading constants into TImode vars

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 :-)


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