Hi!
On Tue, Jun 30, 2020 at 01:58:50AM -0400, Michael Meissner wrote:
> On Mon, Jun 29, 2020 at 01:42:56PM -0500, Segher Boessenkool wrote:
> > On Mon, Jun 29, 2020 at 02:23:22PM -0400, Michael Meissner wrote:
> > > +/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
> > > +
> > > +/* Test that PLI (PADDI) is generated to load a large constant. */
> > > +unsigned long long
> > > +large (void)
> > > +{
> > > + return 0x12345678ULL;
> > > +}
> > > +
> > > +/* { dg-final { scan-assembler {\mpli\M} } } */
> >
> > I have no idea why 64-bit mode (or 64-bit addressing) is needed here.
> > *Is* it needed?
>
> Yes it is needed. Otherwise two separate load immediates would be needed to
> load each part of the DI constant that is held in 2 registers.
But that will work just fine, because one of those insns will be a pli,
exactly as tested for!
> > > --- /dev/null
> > > +++ b/gcc/testsuite/gcc.target/powerpc/prefix-no-update.c
> > > @@ -0,0 +1,51 @@
> > > +/* { dg-do compile } */
> > > +/* { dg-require-effective-target powerpc_prefixed_addr } */
> > > +/* { dg-require-effective-target lp64 } */
> > > +/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
> >
> > For this testcase, I have no idea at all why you want lp64?
>
> Becuase to show the bug you need a stack frame larger than 64K.
I don't see it? (Also, why would that require lp64?)
Segher
