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