[Bug c/106895] New: powerpc64 strange extended inline asm behaviour with register pairs

[Bug c/106895] New: powerpc64 strange extended inline asm behaviour with register pairs

[npiggin at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895

            Bug ID: 106895
           Summary: powerpc64 strange extended inline asm behaviour with
                    register pairs
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: npiggin at gmail dot com
                CC: segher at gcc dot gnu.org
  Target Milestone: ---
            Target: powerpc64le-linux-gnu

This is Debian 12.2.0-1 build.

powerpc64 instructions operating on 128 bits use "even/odd pair" of adjacent
GPRs, where the lower numbered register specifies the pair and it must be an
even number. This code compiled with -O2:

void set128(__int128 val, __int128 *mem)
{
#if WORKAROUND
        asm("");
#endif
        asm("stq %1,%0" : "=m"(*mem) : "r"(val));
}

Results in an invalid even/odd pair:

        stq 3,0(5)
        blr

If compiled with -DWORKAROUND it results in a valid pair:

        mr 10,3
        mr 11,4
        stq 10,0(5)
        blr

[Bug c/106895] powerpc64 strange extended inline asm behaviour with register pairs

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I'm quite sure that 'r' is the wrong constraint letter here.

[Bug target/106895] powerpc64 strange extended inline asm behaviour with register pairs

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895

Peter Bergner <bergner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bergner at gcc dot gnu.org,
                   |                            |meissner at gcc dot gnu.org

--- Comment #2 from Peter Bergner <bergner at gcc dot gnu.org> ---
Using the type __int128 will give you a register pair, but will not guarantee
an even/odd pair.  The "r" constraint will make sure you have a GPR, but again,
doesn't give you an even register.  Looking through our backend, we seem to use
the wQ constraint internally when generating the stq insn.  You could try that.
Mike, is that the correct thing to use here to get an even/odd GPR pair?

[Bug target/106895] powerpc64 strange extended inline asm behaviour with register pairs

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895

Segher Boessenkool <segher at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #3 from Segher Boessenkool <segher at gcc dot gnu.org> ---
wQ is a memory constraint, not a register constraint.

We have no way to express even/odd in register constraints.  You can force
it some other way?

It's a lot easier if you use __atomic_* instead of inline asm?  Like:

void f(unsigned __int128 *addr, unsigned __int128 val)
{
        __atomic_store_n(addr, val, __ATOMIC_RELAXED);
}

Please reopen if you want something in particular to be changed.  Thanks!

[Bug target/106895] powerpc64 strange extended inline asm behaviour with register pairs

[npiggin at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895

Nicholas Piggin <npiggin at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |---
             Status|RESOLVED                    |UNCONFIRMED

--- Comment #4 from Nicholas Piggin <npiggin at gmail dot com> ---
I would like to reopen this. The example provided is not the desired operation,
it was just an example.

Such register-pair instructions in Power are not usable in extended inline asm
without this (except maybe by explicit fixed allocation with clobbers or
register variables which is undesirable).

[Bug target/106895] powerpc64 strange extended inline asm behaviour with register pairs

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement

[Bug target/106895] powerpc64 unable to specify even/odd register pairs in extended inline asm

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895

--- Comment #5 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Constraints are completely the wrong tool for this.  Just use modes, which
*are* the right tool?

[Bug target/106895] powerpc64 unable to specify even/odd register pairs in extended inline asm

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895

--- Comment #6 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Segher Boessenkool from comment #5)
> Constraints are completely the wrong tool for this.  Just use modes, which
> *are* the right tool?

Well you cannot specify modes in the asm, so I think you're saying we need use
the correct type that maps to a internal to GCC mode that has the even/odd
register behavior, so something like:

  unsigned int foo __attribute__ ((mode (XX)));

...where XXmode is the new integer mode that gives us even/odd register pairs? 
Of course we have to be careful about how this all works wrt -m32 versus -m64.

[Bug target/106895] powerpc64 unable to specify even/odd register pairs in extended inline asm

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895

--- Comment #7 from Andreas Schwab <schwab@linux-m68k.org> ---
You are probably looking for a constraint that mirrors the quad_int_reg_operand
predicate.

[Bug target/106895] powerpc64 unable to specify even/odd register pairs in extended inline asm

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895

--- Comment #8 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #6)
> (In reply to Segher Boessenkool from comment #5)
> > Constraints are completely the wrong tool for this.  Just use modes, which
> > *are* the right tool?
> 
> Well you cannot specify modes in the asm, so I think you're saying we need
> use the correct type that maps to a internal to GCC mode that has the
> even/odd register behavior, so something like:
> 
>   unsigned int foo __attribute__ ((mode (XX)));
> 
> ...where XXmode is the new integer mode that gives us even/odd register
> pairs?  Of course we have to be careful about how this all works wrt -m32
> versus -m64.

No, the type there is "unsigned int".  I meant to say exactly what I did say:
just use modes.  Which you indeed do in user code by the mode attribute, yes.

And you do not need a new mode: PTImode should just work.  But the user
specifying that is currently broken it seems?

Without -mpowerpc64 you cannot *have* 128-bit integers in registers.  That
should be
fixed, but you cannot have it in just *two* registers, which is what is
required
here.  For most targets that then means -m64 is required.

[Bug target/106895] powerpc64 unable to specify even/odd register pairs in extended inline asm

[npiggin at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895

--- Comment #9 from Nicholas Piggin <npiggin at gmail dot com> ---
(In reply to Segher Boessenkool from comment #8)
> (In reply to Peter Bergner from comment #6)
> > (In reply to Segher Boessenkool from comment #5)
> > > Constraints are completely the wrong tool for this.  Just use modes, which
> > > *are* the right tool?
> > 
> > Well you cannot specify modes in the asm, so I think you're saying we need
> > use the correct type that maps to a internal to GCC mode that has the
> > even/odd register behavior, so something like:
> > 
> >   unsigned int foo __attribute__ ((mode (XX)));
> > 
> > ...where XXmode is the new integer mode that gives us even/odd register
> > pairs?  Of course we have to be careful about how this all works wrt -m32
> > versus -m64.
> 
> No, the type there is "unsigned int".  I meant to say exactly what I did say:
> just use modes.  Which you indeed do in user code by the mode attribute, yes.
> 
> And you do not need a new mode: PTImode should just work.  But the user
> specifying that is currently broken it seems?

I don't know why constraint is wrong and mode is right or why TI doesn't work
but PTI apparently would, but I'll take anything that works. Could we get PTI
implemented? Does it need a new issue opened?

> 
> Without -mpowerpc64 you cannot *have* 128-bit integers in registers.  That
> should be
> fixed, but you cannot have it in just *two* registers, which is what is
> required
> here.  For most targets that then means -m64 is required.

[Bug target/106895] powerpc64 unable to specify even/odd register pairs in extended inline asm

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895

--- Comment #10 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Nicholas Piggin from comment #9)
> I don't know why constraint is wrong and mode is right

Simple: you would need O(2**T*N) constraints for our existing N register
constraints, together with T features like this.  But only O(2**T) modes at
most.

> or why TI doesn't work but PTI apparently would,

Because this is exactly what PTImode is *for*!

> but I'll take anything that works. Could we
> get PTI implemented? Does it need a new issue opened?

It was implemented in 2013.  The restriction to only even pairs was a bugfix,
also from 2013.

If you have code like

  typedef __int128 __attribute__((mode(PTI))) even;

you get an error like

  error: no data type for mode 'PTI'

This needs fixing.  You can keep it in this PR?

[Bug target/106895] powerpc64 unable to specify even/odd register pairs in extended inline asm

[npiggin at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895

--- Comment #11 from Nicholas Piggin <npiggin at gmail dot com> ---
(In reply to Segher Boessenkool from comment #10)
> (In reply to Nicholas Piggin from comment #9)
> > I don't know why constraint is wrong and mode is right
> 
> Simple: you would need O(2**T*N) constraints for our existing N register
> constraints, together with T features like this.  But only O(2**T) modes at
> most.

I guess that would be annoying if you couldn't have modifiers on constraints or
a bad algorithm for working them out. Fair enough.

> 
> > or why TI doesn't work but PTI apparently would,
> 
> Because this is exactly what PTImode is *for*!

Right I accept it is, I meant I just would not have been able to work it out
(assuming if PTI was documented it would be "Partial Tetra Integer" and be no
more useful than the other P?I type documentation.

> 
> > but I'll take anything that works. Could we
> > get PTI implemented? Does it need a new issue opened?
> 
> It was implemented in 2013.  The restriction to only even pairs was a bugfix,
> also from 2013.
> 
> If you have code like
> 
>   typedef __int128 __attribute__((mode(PTI))) even;
> 
> you get an error like
> 
>   error: no data type for mode 'PTI'
> 
> This needs fixing.  You can keep it in this PR?

Sure,  that would be much appreciated.

[Bug target/106895] powerpc64 unable to specify even/odd register pairs in extended inline asm

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895

--- Comment #12 from Segher Boessenkool <segher at gcc dot gnu.org> ---
> I guess that would be annoying if you couldn't have modifiers on constraints

There is no such thing as "operand modifiers".  There are *output* modifiers:
they change how an operand is *printed*, they do not change the operand in any
way, shape, or form.

> or a bad algorithm for working them out. Fair enough.

No idea what you mean here?

> > > or why TI doesn't work but PTI apparently would,
> > 
> > Because this is exactly what PTImode is *for*!
> 
> Right I accept it is, I meant I just would not have been able to work it out
> (assuming if PTI was documented it would be "Partial Tetra Integer" and be
> no more useful than the other P?I type documentation.

For the rs6000 port, multi-register operands are not restricted to aligned
register numbers ("even/odd pairs").  (Some other ports do have this).  We use
the existing PTI mode for that (it also can be allocated in GPRs only, never in
VSRs, unlike TImode).

"Partial" does not have much meaning here.  A minority of ports use partial
integer words for what they were introduced for originally: modes that are
smaller than a full register, say, a 24-bit mode when registers are 32 bits.

We use it as another integer mode that is the same size.  It is unfortunate
that we still have to resort to such tricks.

[Bug target/106895] powerpc64 unable to specify even/odd register pairs in extended inline asm

[npiggin at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895

--- Comment #13 from Nicholas Piggin <npiggin at gmail dot com> ---
(In reply to Segher Boessenkool from comment #12)
> > I guess that would be annoying if you couldn't have modifiers on constraints
> 
> There is no such thing as "operand modifiers".  There are *output* modifiers:
> they change how an operand is *printed*, they do not change the operand in
> any
> way, shape, or form.

No I mean like x, y, z for different register pairs, or Pn where n=0..4, eI,
eP, eQ for different immediates.

If they're practically just implemented as another constraint, what is really
the big deal with adding a even/odd GPR pair constraint anyway? You say it's
2^T^N additional constraints. As far as I can tell it turns out to be one extra
constrain, or maybe 2 if you need one that excludes r0. 

> 
> > or a bad algorithm for working them out. Fair enough.
> 
> No idea what you mean here?

If you can't deal well with more constraints.

> 
> > > > or why TI doesn't work but PTI apparently would,
> > > 
> > > Because this is exactly what PTImode is *for*!
> > 
> > Right I accept it is, I meant I just would not have been able to work it out
> > (assuming if PTI was documented it would be "Partial Tetra Integer" and be
> > no more useful than the other P?I type documentation.
> 
> For the rs6000 port, multi-register operands are not restricted to aligned
> register numbers ("even/odd pairs").  (Some other ports do have this).  We
> use
> the existing PTI mode for that (it also can be allocated in GPRs only, never
> in
> VSRs, unlike TImode).
> 
> "Partial" does not have much meaning here.  A minority of ports use partial
> integer words for what they were introduced for originally: modes that are
> smaller than a full register, say, a 24-bit mode when registers are 32 bits.
> 
> We use it as another integer mode that is the same size.  It is unfortunate
> that we still have to resort to such tricks.

Okay that explains it, thank you.