[Bug target/98519] New: rs6000: @pcrel unsupported on this instruction error in pveclib

[Bug target/98519] New: rs6000: @pcrel unsupported on this instruction error in pveclib

[bergner at gcc dot gnu.org]

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

            Bug ID: 98519
           Summary: rs6000: @pcrel unsupported on this instruction error
                    in pveclib
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bergner at gcc dot gnu.org
  Target Milestone: ---

Using latest GCC trunk and binutils trunk from today, we see the following
error on a reduced test case from pveclib:

bergner@pike:~/gcc/BUGS/PVECLIB$ cat bug.i
typedef __attribute__((altivec(vector__))) double vf64_t;
static double test_f64[16];
vf64_t
bug (void)
{
  vf64_t j0;
  __asm__("lxsd%X1 %0,%1;" : "=v" (j0) : "m" (test_f64));
  return j0;
}

bergner@pike:~/gcc/BUGS/PVECLIB$
/home/bergner/gcc/build/gcc-fsf-mainline-pveclib-debug/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-pveclib-debug/gcc -c -O2
-mcpu=power10 bug.i
/tmp/ccNVSo9c.s: Assembler messages:
/tmp/ccNVSo9c.s:15: Warning: @pcrel unsupported on this instruction
/tmp/ccNVSo9c.s:15: Error: unsupported relocation for DS offset field
/tmp/ccNVSo9c.s:15: Error: missing operand

The problematic insn is:

        lxsd 2,.LANCHOR0@pcrel;

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[bergner at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
                 CC|                            |dje at gcc dot gnu.org,
                   |                            |meissner at gcc dot gnu.org,
                   |                            |munroesj at gcc dot gnu.org,
                   |                            |segher at gcc dot gnu.org,
                   |                            |wschmidt at gcc dot gnu.org
   Last reconfirmed|                            |2021-01-04
             Target|                            |powerpc64le-linux
     Ever confirmed|0                           |1

--- Comment #1 from Peter Bergner <bergner at gcc dot gnu.org> ---
Steve reported the error and I have confirmed it.  I believe this also fails on
GCC 10 (ie, everywhere POWER10 is supported).

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner <meissner at gcc dot gnu.org> ---
That fell off the plate.  I imagine we are going to need a hook with asm that
makes sure none of the memory references are PC-relative.

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[bergner at gcc dot gnu.org]

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

--- Comment #3 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Michael Meissner from comment #2)
> That fell off the plate.  I imagine we are going to need a hook with asm
> that makes sure none of the memory references are PC-relative.

I guess since we cannot see which mnemonic is used in the inline asm, we have
to be conservative and always reject pc-relative addresses with the "m"
constraint (other constraints too?).

Do we need to create a new memory constraint inline asm users can use to say
pc-relative addresses are ok?  How does x86 handle this?

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool <segher at gcc dot gnu.org> ---
"m" is already handled differently for inline asm, so perhaps we can just
extend that?  ("m" in machine descriptions is "m<>" in asm, for example).

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[munroesj at gcc dot gnu.org]

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

--- Comment #5 from Steven Munroe <munroesj at gcc dot gnu.org> ---
I would think you need to look at the instruction and the "m" constraint.

In this case lxsd%X1 would need to be converted to plxsd and the "m" constraint
would have to allow @pcrel. I would think a static variable would be valid, but
stack local or explicit pointer with (nonconst) offset/index would not.

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool <segher at gcc dot gnu.org> ---
You cannot look at the instruction, ever.  The inline asm template is
just text, nothing else.  You cannot assume it is valid instructions.

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[munroesj at gcc dot gnu.org]

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

--- Comment #7 from Steven Munroe <munroesj at gcc dot gnu.org> ---
Then you have problem as @pcrel is never valid for an instruction like lxsd%X1.

Seems like you will need a new constrain or modifier specific to @pcrel.

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[segher at gcc dot gnu.org]

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

--- Comment #8 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Yes, "m" can not allow PC-relative, in inline asm (just think of all existing
code that uses "m").

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[meissner at gcc dot gnu.org]

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

--- Comment #9 from Michael Meissner <meissner at gcc dot gnu.org> ---
I agree with Segher.  Given the 'magic' we need to add the missing 'p' and set
the length for normal RTL, I don't see any reasonable way to add it to asm.  We
will just need to use a hook (or make one) to make sure no PCREL addresses are
passed to asm.

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[wschmidt at gcc dot gnu.org]

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

--- Comment #10 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
But it seems we would also need a new constraint that does permit PC-relative
addresses, since new code will/may not have a TOC.

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[segher at gcc dot gnu.org]

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

--- Comment #11 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Bill Schmidt from comment #10)
> But it seems we would also need a new constraint that does permit
> PC-relative addresses, since new code will/may not have a TOC.

How could that work?  You need different assembler code for pcrel
accesses!  *Sometimes* just prefixing a "p" is enough, maybe we
should do something for that, but we cannot magically fix the
general problem.

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[wschmidt at gcc dot gnu.org]

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

--- Comment #12 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
Right...but if somebody specifies an instruction with a 'p' that is
legitimately a pc-relative instruction, we don't want to say that the memory
operand can't use PC-relative addressing, do we?  I just want to be sure people
can use the new instructions as intended in assembly.

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[bergner at gcc dot gnu.org]

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

--- Comment #13 from Peter Bergner <bergner at gcc dot gnu.org> ---
We are talking inline asm here, correct?  If so, the user is fully in charge of
using the correct mnemonic.  It just seems to me that "m" should always mean
non pc-relative addresses for all the existing inline asm and we should have a
new constraint that allows pc-relative addressing.  The user would just need to
ensure to use the correct mnemonic with the correct constraint.  Or am I
missing something here?

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[wschmidt at gcc dot gnu.org]

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

--- Comment #14 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
I agree, Peter.

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[meissner at gcc dot gnu.org]

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

--- Comment #15 from Michael Meissner <meissner at gcc dot gnu.org> ---
FWIW, the hook that will need to be modified is rs6000_md_asm_adjust in
rs6000.c.  It appears you are passed the outputs, the inputs, the constraints,
and the clobbers.  Right now, we just mark the CA register as being clobbered.

The simplest approach is just to prohibit both prefixed and pc-relative
addresses from being passed to the asm.  If a prefixed/pc-relative address is
passed as an input/output, we would need to force the address to a base
register, and rewrite the input/output to use that new base register.  That
will allow traditional code to work.

I suspect if we wanted to enable users to actually do prefixed loads/stores in
the asm, we would need a constraint that says this address must be prefixed. 
Possibly another one for pc-relative.  And then the hook would allow the
address without modification.

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[segher at gcc dot gnu.org]

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

--- Comment #16 from Segher Boessenkool <segher at gcc dot gnu.org> ---
No, this cannot be fixed in this hook, or in any other hook.  The compiler
can never see *at all* what instructions there are, the template is just a
piece of text to it (there could be assembler macros in play, if you need
to see a practical reason).

We just need new constraints, as Bill and Peter agree.

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[segher at gcc dot gnu.org]

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

--- Comment #17 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(What i was referring to in Comment 4 was asm_operand_ok in recog.c --
it may need some surgery if we need to hook into that).

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[amodra at gmail dot com]

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

Alan Modra <amodra at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amodra at gmail dot com

--- Comment #18 from Alan Modra <amodra at gmail dot com> ---
Isn't this a bug in the assembly?  We've changed the ABI, there is no way
anyone can expect all old asm to work with power10 pcrel.  To support pcrel you
need new asm.

#ifdef __PCREL__
__asm__ (pcrel version);
#else
__asm__ (non-pcrel version);
#endif

No need for special constraints, I think.  (And not sufficient if we had them.)

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[segher at gcc dot gnu.org]

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

--- Comment #19 from Segher Boessenkool <segher at gcc dot gnu.org> ---
We cannot allow "m" to allow pcrel memory accesses, because most
existing inline assembler code will break then.  So we then need
some way to tell the compiler that some instruction *does* allow
pcrel memory (or even *requires* it).

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[bergner at gcc dot gnu.org]

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

--- Comment #20 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Alan Modra from comment #18)
> Isn't this a bug in the assembly?  We've changed the ABI, there is no way
> anyone can expect all old asm to work with power10 pcrel.  To support pcrel
> you need new asm.
> 
> #ifdef __PCREL__
> __asm__ (pcrel version);
> #else
> __asm__ (non-pcrel version);
> #endif
> 
> No need for special constraints, I think.  (And not sufficient if we had
> them.)

I agree with Segher that we can't state that all old inline asm that uses "m"
is buggy if/when compiled with -mcpu=power10.  There's just way too much use of
it.

That said, I'm interested in why you don't think a new special pcrel constraint
would be sufficient?

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[meissner at gcc dot gnu.org]

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

--- Comment #21 from Michael Meissner <meissner at gcc dot gnu.org> ---
I have patches that fix the problem in the hook.

My original idea of not allowing prefixed insns in the hook doesn't work
because when the hook is called, it only sees pseudo registers.

So what my patch does instead is to change the constraints.  It makes 3 new
constraints:

    em -- Like m, but do not allow prefixed memory
    eo -- Like o, but do not allow prefixed memory
    ep -- Only accept prefixed memory

Now, 'ep' isn't needed, but I added it to give people a way to write asm using
prefixed instructions.  If 'eo' and 'em' are ok, but we don't want to add 'ep',
that is fine, it is simple to remove.

The hook then goes through the constraints, and changes 'm' to 'em', and 'o' to
'eo'.  That way old memory asm's won't see prefixed addresses.  If the register
allocator sees a prefixed address, it takes the address using 'pla' and
substitutes a base register.

In know in general, the preference is not to add new constraints, but I feel by
adding the constraints, it makes it to be a simpler problem that writing a new
RTL pass or adding new target hooks.

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[meissner at gcc dot gnu.org]

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

Michael Meissner <meissner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |meissner at gcc dot gnu.org

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[segher at gcc dot gnu.org]

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

--- Comment #22 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Don't replace the constraints.  For one thing, this is very hard to do
correctly.  Just make the "m" constraint not allow prefixed memory in
asms, like I said above.  (So all "general_operand" even!)

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[meissner at gcc dot gnu.org]

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

Michael Meissner <meissner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
           Assignee|meissner at gcc dot gnu.org        |unassigned at gcc dot gnu.org

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[meissner at gcc dot gnu.org]

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

--- Comment #23 from Michael Meissner <meissner at gcc dot gnu.org> ---
Obviously one approach is to use the recog_data.is_asm field to determine if
the %m constraint is in an asm and restrict it to non-prefixed memory
addresses.

However, this doesn't work, because is_asm is not reliably set.

For example in this program:

static int x;
int *p_x = &x;

int get (void)
{
  int a;
  __asm__ ("lwz%U0%X0 %0,%1" : "=r" (a) : "m" (x));
  return a;
}

And we look at calls to satisfies_constraint_m, the is_asm field it not set for
each of the references:

Current directory is
/home/meissner/fsf-build-x86_64/work036-powerpc64le-linux/gcc/
GNU gdb (GDB) 11.0.50.20210212-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from
/home/meissner/fsf-build-x86_64/work036-powerpc64le-linux/gcc/cc1...
.gdbinit:14: Error in sourced command file:
/home/meissner/fsf-src/work036/gcc/gdbinit.in:323: Error in sourced command
file:
Python scripting is not supported in this copy of GDB.
(gdb) b ira.c:5527
Breakpoint 1 at 0xa10c45: file /home/meissner/fsf-src/work036/gcc/ira.c, line
5527.
# the above line is after the initial setup that IRA does.
(gdb) b satisfies_constraint_m
Breakpoint 2 at 0x1363e30: satisfies_constraint_m. (2 locations)
(gdb) dis 2
(gdb) commands 2
Type commands for breakpoint(s) 2, one per line.
End with a line saying just "end".
>print op
>pr
>print recog_data.is_asm
>(gdb) r -O2 -quiet -mcpu=power10 foo02.c

Starting program:
/home/meissner/fsf-build-x86_64/work036-powerpc64le-linux/gcc/cc1 -O2 -quiet
-mcpu=power10 foo02.c
Breakpoint 1, ira (f=0x0) at /home/meissner/fsf-src/work036/gcc/ira.c:5527
(gdb) en 2
(gdb) c
Continuing.

Breakpoint 2, satisfies_constraint_m (op=0x7ffff0de35e8) at tm-constrs.h:10
$1 = (rtx) 0x7ffff0de35e8
(mem/c:SI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182]) [1 x+0 S4 A32])
$2 = false
# Note, is_asm should be true here

(gdb) where
#0  satisfies_constraint_m (op=0x7ffff0de35e8) at tm-constrs.h:10
#1  0x0000000000a59ba7 in constraint_satisfied_p (c=CONSTRAINT_m,
x=0x7ffff0de35e8) at ./tm-preds.h:258
#2  valid_address_p (op=op@entry=0x7ffff0de35e8, ad=ad@entry=0x7fffffffbc80,
constraint=constraint@entry=CONSTRAINT_m)
    at /home/meissner/fsf-src/work036/gcc/lra-constraints.c:415
#3  0x0000000000a612d6 in process_address_1 (nop=-17280,
check_only_p=<optimized out>, before=0x7fffffffbe50, after=<optimized out>)
    at /home/meissner/fsf-src/work036/gcc/lra-constraints.c:3531
#4  0x0000000000a63101 in process_address (after=0x7fffffffbe58,
before=0x7fffffffbe50, check_only_p=false, nop=1)
    at /home/meissner/fsf-src/work036/gcc/lra-constraints.c:3739
#5  curr_insn_transform (check_only_p=<optimized out>) at
/home/meissner/fsf-src/work036/gcc/lra-constraints.c:4054
#6  0x0000000000a681ee in lra_constraints (first_p=<optimized out>) at
/home/meissner/fsf-src/work036/gcc/lra-constraints.c:5143
#7  0x0000000000a5089b in lra (f=<optimized out>) at
/home/meissner/fsf-src/work036/gcc/lra.c:2336
#8  0x0000000000a0bcfa in do_reload () at
/home/meissner/fsf-src/work036/gcc/ira.c:5827
#9  (anonymous namespace)::pass_reload::execute (this=<optimized out>) at
/home/meissner/fsf-src/work036/gcc/ira.c:6013
#10 0x0000000000b133fd in execute_one_pass (pass=0x20b66c0) at
/home/meissner/fsf-src/work036/gcc/passes.c:2567
#11 0x0000000000b13da0 in execute_pass_list_1 (pass=0x20b66c0) at
/home/meissner/fsf-src/work036/gcc/passes.c:2656
#12 0x0000000000b13db2 in execute_pass_list_1 (pass=0x20b54c0) at
/home/meissner/fsf-src/work036/gcc/passes.c:2657
#13 0x0000000000b13dd9 in execute_pass_list (fn=0x7ffff0dd8000, pass=<optimized
out>) at /home/meissner/fsf-src/work036/gcc/passes.c:2667
#14 0x00000000007a34e1 in cgraph_node::expand (this=0x7ffff0fd6440) at
/home/meissner/fsf-src/work036/gcc/context.h:48
#15 0x00000000007a49f0 in expand_all_functions () at
/home/meissner/fsf-src/work036/gcc/cgraphunit.c:1995
#16 symbol_table::compile (this=0x7ffff0fce000) at
/home/meissner/fsf-src/work036/gcc/cgraphunit.c:2359
#17 0x00000000007a7398 in symbol_table::compile (this=0x7ffff0fce000) at
/home/meissner/fsf-src/work036/gcc/cgraphunit.c:2272
#18 symbol_table::finalize_compilation_unit (this=0x7ffff0fce000) at
/home/meissner/fsf-src/work036/gcc/cgraphunit.c:2540
#19 0x0000000000bed568 in compile_file () at
/home/meissner/fsf-src/work036/gcc/toplev.c:482
#20 0x00000000005f4a17 in do_compile () at
/home/meissner/fsf-src/work036/gcc/toplev.c:2197
#21 toplev::main (this=this@entry=0x7fffffffcdde, argc=<optimized out>,
argc@entry=5, argv=<optimized out>, argv@entry=0x7fffffffced8)
    at /home/meissner/fsf-src/work036/gcc/toplev.c:2336
#22 0x00000000005f73af in main (argc=5, argv=0x7fffffffced8) at
/home/meissner/fsf-src/work036/gcc/main.c:39

(gdb) c
Continuing.

Breakpoint 2, satisfies_constraint_m (op=0x7ffff0de35e8) at
/home/meissner/fsf-src/work036/gcc/common.md:27
$3 = (rtx) 0x7ffff0de35e8
(mem/c:SI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182]) [1 x+0 S4 A32])
$4 = false
(gdb) c
Continuing.

Breakpoint 2, satisfies_constraint_m (op=0x7ffff0de35e8) at tm-constrs.h:10
$5 = (rtx) 0x7ffff0de35e8
(mem/c:SI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182]) [1 x+0 S4 A32])
$6 = false
(gdb) c
Continuing.

Breakpoint 2, satisfies_constraint_m (op=0x7ffff0de35e8) at
/home/meissner/fsf-src/work036/gcc/common.md:27
$7 = (rtx) 0x7ffff0de35e8
(mem/c:SI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182]) [1 x+0 S4 A32])
$8 = false
(gdb) c
Continuing.

Breakpoint 2, satisfies_constraint_m (op=0x7ffff0de35e8) at tm-constrs.h:10
$9 = (rtx) 0x7ffff0de35e8
(mem/c:SI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182]) [1 x+0 S4 A32])
$10 = true
(gdb) c
Continuing.

Breakpoint 2, satisfies_constraint_m (op=0x7ffff0de35e8) at
/home/meissner/fsf-src/work036/gcc/common.md:27
$11 = (rtx) 0x7ffff0de35e8
(mem/c:SI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182]) [1 x+0 S4 A32])
$12 = true
(gdb) c
Continuing.

Breakpoint 2, satisfies_constraint_m (op=0x7ffff0de35e8) at tm-constrs.h:10
$13 = (rtx) 0x7ffff0de35e8
(mem/c:SI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182]) [1 x+0 S4 A32])
$14 = true
(gdb) c
Continuing.

Breakpoint 2, satisfies_constraint_m (op=0x7ffff0de35e8) at
/home/meissner/fsf-src/work036/gcc/common.md:27
$15 = (rtx) 0x7ffff0de35e8
(mem/c:SI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182]) [1 x+0 S4 A32])
$16 = true
(gdb) c
Continuing.

Breakpoint 2, satisfies_constraint_m (op=0x7ffff0de35e8) at tm-constrs.h:10
$17 = (rtx) 0x7ffff0de35e8
(mem/c:SI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182]) [1 x+0 S4 A32])
$18 = true
(gdb) c
Continuing.

Breakpoint 2, satisfies_constraint_m (op=0x7ffff0de35e8) at
/home/meissner/fsf-src/work036/gcc/common.md:27
$19 = (rtx) 0x7ffff0de35e8
(mem/c:SI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182]) [1 x+0 S4 A32])
$20 = true
(gdb) c
Continuing.

Breakpoint 2, satisfies_constraint_m (op=0x7ffff0de35e8) at tm-constrs.h:10
$21 = (rtx) 0x7ffff0de35e8
(mem/c:SI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182]) [1 x+0 S4 A32])
$22 = true
(gdb) c
Continuing.

Breakpoint 2, satisfies_constraint_m (op=0x7ffff0de35e8) at
/home/meissner/fsf-src/work036/gcc/common.md:27
$23 = (rtx) 0x7ffff0de35e8
(mem/c:SI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182]) [1 x+0 S4 A32])
$24 = true
(gdb) c
Continuing.

Breakpoint 2, satisfies_constraint_m (op=0x7ffff0de35e8) at tm-constrs.h:10
$25 = (rtx) 0x7ffff0de35e8
(mem/c:SI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182]) [1 x+0 S4 A32])
$26 = true
(gdb) c
Continuing.

Breakpoint 2, satisfies_constraint_m (op=0x7ffff0de35e8) at
/home/meissner/fsf-src/work036/gcc/common.md:27
$27 = (rtx) 0x7ffff0de35e8
(mem/c:SI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182]) [1 x+0 S4 A32])
$28 = true
(gdb) c
Continuing.

Breakpoint 2, satisfies_constraint_m (op=0x7ffff0de35e8) at tm-constrs.h:10
$29 = (rtx) 0x7ffff0de35e8
(mem/c:SI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182]) [1 x+0 S4 A32])
$30 = true
(gdb) c
Continuing.

Breakpoint 2, satisfies_constraint_m (op=0x7ffff0de35e8) at
/home/meissner/fsf-src/work036/gcc/common.md:27
$31 = (rtx) 0x7ffff0de35e8
(mem/c:SI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182]) [1 x+0 S4 A32])
$32 = true
(gdb) c
Continuing.
[Inferior 1 (process 4757) exited normally]
(gdb) 


If we change rs6000_legitimate_address_p to return false if we have a prefixed
address and we are in asm, we get an insn not found error:

--- /home/meissner/tmp/gcc-tmp/TskwFJ_rs6000.c  2021-02-16 11:44:05.520201674
-0500
+++ gcc/config/rs6000/rs6000.c  2021-02-16 11:41:41.444740394 -0500
@@ -9532,7 +9532,7 @@ rs6000_legitimate_address_p (machine_mod

   /* Handle prefixed addresses (PC-relative or 34-bit offset).  */
   if (address_is_prefixed (x, mode, NON_PREFIXED_DEFAULT))
-    return 1;
+    return !recog_data.is_asm;

   /* Handle restricted vector d-form offsets in ISA 3.0.  */
   if (quad_offset_p)

$ file="foo02"; ./xgcc -B./ -O2 -mcpu=power10  -save-temps -c $file.c 
foo02.c:9:1: error: unrecognizable insn:
    9 | }
      | ^
(insn 7 5 12 2 (parallel [
            (set (reg:SI 3 3 [orig:118 a ] [118])
                (asm_operands:SI ("lwz%U0%X0 %0,%1") ("=r") 0 [
                        (mem/c:SI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182])
[1 x+0 S4 A32])
                    ]
                     [
                        (asm_input:SI ("m") foo02.c:7)
                    ]
                     [] foo02.c:7))
            (clobber (reg:SI 98 ca))
        ]) "foo02.c":7:3 -1
     (nil))
during RTL pass: reload
foo02.c:9:1: internal compiler error: in extract_constrain_insn, at
recog.c:2670
0x4d50db _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
        /home/meissner/fsf-src/work036/gcc/rtl-error.c:108
0x4d50f7 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
        /home/meissner/fsf-src/work036/gcc/rtl-error.c:116
0xb5907f extract_constrain_insn(rtx_insn*)
        /home/meissner/fsf-src/work036/gcc/recog.c:2670
0xa4d0a7 check_rtl
        /home/meissner/fsf-src/work036/gcc/lra.c:2087
0xa510ad lra(_IO_FILE*)
        /home/meissner/fsf-src/work036/gcc/lra.c:2505
0xa0bcf9 do_reload
        /home/meissner/fsf-src/work036/gcc/ira.c:5827
0xa0bcf9 execute
        /home/meissner/fsf-src/work036/gcc/ira.c:6013
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[meissner at gcc dot gnu.org]

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

--- Comment #24 from Michael Meissner <meissner at gcc dot gnu.org> ---
Obviously I had a small typo in the previous example (using %U0%X0 instead of
%U1%X1) which did not matter, but here is the corrected example:

static int x;
int *p_x = &x;

int get (void)
{
  int a;
  __asm__ ("lwz%U1%X1 %0,%1" : "=r" (a) : "m" (x));
  return a;
}

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[meissner at gcc dot gnu.org]

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

--- Comment #25 from Michael Meissner <meissner at gcc dot gnu.org> ---
Created attachment 50201
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50201&action=edit
Example code for both input and output %m usage

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[segher at gcc dot gnu.org]

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

--- Comment #26 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Can you show the code you tried in comment 23?  It is near impossible to see
what happened there without that.

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[bergner at gcc dot gnu.org]

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

--- Comment #27 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Michael Meissner from comment #23)
> If we change rs6000_legitimate_address_p to return false if we have a
> prefixed address and we are in asm, we get an insn not found error:
> 
> --- /home/meissner/tmp/gcc-tmp/TskwFJ_rs6000.c  2021-02-16
> 11:44:05.520201674 -0500
> +++ gcc/config/rs6000/rs6000.c  2021-02-16 11:41:41.444740394 -0500
> @@ -9532,7 +9532,7 @@ rs6000_legitimate_address_p (machine_mod
>  
>    /* Handle prefixed addresses (PC-relative or 34-bit offset).  */
>    if (address_is_prefixed (x, mode, NON_PREFIXED_DEFAULT))
> -    return 1;
> +    return !recog_data.is_asm;
>  
>    /* Handle restricted vector d-form offsets in ISA 3.0.  */
>    if (quad_offset_p)

I don't think this change is correct as is, since pcrel addresses could be
legitimate in asm if we had a constraint the user could use.  I think this
would also have to check that the constraint being used isn't the new pcrel
constraint.



> And we look at calls to satisfies_constraint_m, the is_asm field it not set
> for each of the references:

The above said, is this the real problem?  Ie, should we fix the is_asm field
not always being correctly set so we can make a change here rather than in
rs6000_legitimate_address_p?

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[segher at gcc dot gnu.org]

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

--- Comment #28 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #27)
> (In reply to Michael Meissner from comment #23)
> > If we change rs6000_legitimate_address_p to return false if we have a
> > prefixed address and we are in asm, we get an insn not found error:
> > 
> > --- /home/meissner/tmp/gcc-tmp/TskwFJ_rs6000.c  2021-02-16
> > 11:44:05.520201674 -0500
> > +++ gcc/config/rs6000/rs6000.c  2021-02-16 11:41:41.444740394 -0500
> > @@ -9532,7 +9532,7 @@ rs6000_legitimate_address_p (machine_mod
> >  
> >    /* Handle prefixed addresses (PC-relative or 34-bit offset).  */
> >    if (address_is_prefixed (x, mode, NON_PREFIXED_DEFAULT))
> > -    return 1;
> > +    return !recog_data.is_asm;
> >  
> >    /* Handle restricted vector d-form offsets in ISA 3.0.  */
> >    if (quad_offset_p)
> 
> I don't think this change is correct as is, since pcrel addresses could be
> legitimate in asm

All prefixed addresses, pcrel or R=0, are valid always.  The original code
is correct.

But lxsd cannot use "m" as constraint anyway.  It needs "wY", and that will
work fine here?

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[bergner at gcc dot gnu.org]

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

--- Comment #29 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Segher Boessenkool from comment #28)
> All prefixed addresses, pcrel or R=0, are valid always.  The original code
> is correct.

Well they're only valid when compiling for power10, but we probably don't
generate pcrel addresses unless we're compiling for power10, so ok.


> But lxsd cannot use "m" as constraint anyway.  It needs "wY", and that will
> work fine here?

"wY" might be correct for lxsd, but I don't see how using "wY" instead of "m"
will stop us from generating a pcrel here, since mem_operand_ds_form() doesn't
disallow pcrel addresses.  Ie, lxsd is a red herring to the actual bug.

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[segher at gcc dot gnu.org]

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

--- Comment #30 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #29)
> (In reply to Segher Boessenkool from comment #28)
> > All prefixed addresses, pcrel or R=0, are valid always.  The original code
> > is correct.
> 
> Well they're only valid when compiling for power10, but we probably don't
> generate pcrel addresses unless we're compiling for power10, so ok.

Of course, generating prefixed instructions for a CPU that does not support
that is not valid.  The same is true for any optional instruction or addressing
form.  GCC does not generate those.

> > But lxsd cannot use "m" as constraint anyway.  It needs "wY", and that will
> > work fine here?
> 
> "wY" might be correct for lxsd, but I don't see how using "wY" instead of
> "m" will stop us from generating a pcrel here, since mem_operand_ds_form()
> doesn't disallow pcrel addresses.  Ie, lxsd is a red herring to the actual
> bug.

"m" is not correct for "lxsd" (and even "Y" is only because we now require
"Y<>" to allow update form insns).

I mistakenly though that "wY" does not allow prefixed.  But it does.

We have to disallow all (*all*) operands that require prefixed insns, until
we can handle those properly.

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[bergner at gcc dot gnu.org]

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

--- Comment #31 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Segher Boessenkool from comment #30)
> We have to disallow all (*all*) operands that require prefixed insns, until
> we can handle those properly.

So if we can't disallow pcrel addresses in asm operands in 
rs6000_legitimate_address_p, then where can we disallow them when they're used
with all of the current memory constraints?  Ie, not the new pcrel address
friendly constraint we don't have yet?

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

[segher at gcc dot gnu.org]

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

--- Comment #32 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #31)
> (In reply to Segher Boessenkool from comment #30)
> > We have to disallow all (*all*) operands that require prefixed insns, until
> > we can handle those properly.
> 
> So if we can't disallow pcrel addresses in asm operands in 
> rs6000_legitimate_address_p, then where can we disallow them when they're
> used with all of the current memory constraints?  Ie, not the new pcrel
> address friendly constraint we don't have yet?

Maybe we can do something like

  "m!"(xx)

to mean prefixed addressing is allowed.  This would be handled adjacent to
where we handle "m<>" already (in recog.cc mostly).