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

2022-10-10 Thread segher at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

--- Comment #32 from Segher Boessenkool  ---
(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).

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

2022-10-03 Thread bergner at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

--- Comment #31 from Peter Bergner  ---
(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

2022-10-03 Thread segher at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

--- Comment #30 from Segher Boessenkool  ---
(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

2022-10-03 Thread bergner at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

--- Comment #29 from Peter Bergner  ---
(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

2022-10-03 Thread segher at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

--- Comment #28 from Segher Boessenkool  ---
(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

2022-10-03 Thread bergner at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

--- Comment #27 from Peter Bergner  ---
(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

2021-02-16 Thread segher at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

--- Comment #26 from Segher Boessenkool  ---
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

2021-02-16 Thread meissner at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

--- Comment #25 from Michael Meissner  ---
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

2021-02-16 Thread meissner at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

--- Comment #24 from Michael Meissner  ---
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

2021-02-16 Thread meissner at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

--- Comment #23 from Michael Meissner  ---
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 
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:
.
Find the GDB manual and other documentation resources online at:
.

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=0x70de35e8) at tm-constrs.h:10
$1 = (rtx) 0x70de35e8
(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=0x70de35e8) at tm-constrs.h:10
#1  0x00a59ba7 in constraint_satisfied_p (c=CONSTRAINT_m,
x=0x70de35e8) at ./tm-preds.h:258
#2  valid_address_p (op=op@entry=0x70de35e8, ad=ad@entry=0x7fffbc80,
constraint=constraint@entry=CONSTRAINT_m)
at /home/meissner/fsf-src/work036/gcc/lra-constraints.c:415
#3  0x00a612d6 in process_address_1 (nop=-17280,
check_only_p=, before=0x7fffbe50, after=)
at /home/meissner/fsf-src/work036/gcc/lra-constraints.c:3531
#4  0x00a63101 in process_address (after=0x7fffbe58,
before=0x7fffbe50, check_only_p=false, nop=1)
at /home/meissner/fsf-src/work036/gcc/lra-constraints.c:3739
#5  curr_insn_transform (check_only_p=) at
/home/meissner/fsf-src/work036/gcc/lra-constraints.c:4054
#6  0x00a681ee in lra_constraints (first_p=) at
/home/meissner/fsf-src/work036/gcc/lra-constraints.c:5143
#7  0x00a5089b in lra (f=) at
/home/meissner/fsf-src/work036/gcc/lra.c:2336
#8  0x00a0bcfa in do_reload () at
/home/meissner/fsf-src/work036/gcc/ira.c:5827
#9  (anonymous namespace)::pass_reload::execute (this=) at
/home/meissner/fsf-src/work036/gcc/ira.c:6013
#10 0x00b133fd in execute_one_pass (pass=0x20b66c0) at
/home/meissner/fsf-src/work036/gcc/passes.c:2567
#11 0x00b13da0 in execute_pass_list_1 (pass=0x20b66c0) at
/home/meissner/fsf-src/work036/gcc/passes.c:2656
#12 0x00b13db2 in execute_pass_list_1 (pass=0x20b54c0) at
/home/meissner/fsf-src/work036/gcc/passes.c:2657
#13 0x00b13dd9 in execute_pass_list (fn=0x70dd8000, pass=) at /home/meissner/fsf-src/work036/gcc/passes.c:2667
#14 0x007a34e1 in cgraph_node::expand (this=0x70fd6440) at
/home/meissner/fsf-src/work036/gcc/context.h:48
#15 0x007a49f0 in expand_all_functions () at
/home/meissner/fsf-src/work036/gcc/cgraphunit.c:1995
#16 symbol_table::compile (this=0x70fce000) at
/home/meissner/fsf-src/work036/gcc/cgraphunit.c:2359
#17 0x007a7398 in symbol_table::compile (this=0x70fce000) at
/home/meissner/fsf-src/work036/gcc/cgraphunit.c:2272
#18 symbol_table::finalize_compilation_unit (this=0x70fce000) at
/home/meissner/fsf-src/work036/gcc/cgraphunit.c:2540
#19 0x00bed568 in compile_file () at
/home/meissner/fsf-src/work036/gcc/toplev.c:482
#20 0x005f4a17 in do_compile () at
/home/meissner/fsf-src/work036/gcc/toplev.c:2197
#21 t

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

2021-02-02 Thread meissner at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

Michael Meissner  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

2021-02-02 Thread segher at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

--- Comment #22 from Segher Boessenkool  ---
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

2021-02-01 Thread meissner at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

Michael Meissner  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

2021-02-01 Thread meissner at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

--- Comment #21 from Michael Meissner  ---
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

2021-01-23 Thread bergner at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

--- Comment #20 from Peter Bergner  ---
(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

2021-01-22 Thread segher at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

--- Comment #19 from Segher Boessenkool  ---
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

2021-01-21 Thread amodra at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

Alan Modra  changed:

   What|Removed |Added

 CC||amodra at gmail dot com

--- Comment #18 from Alan Modra  ---
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

2021-01-13 Thread segher at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

--- Comment #17 from Segher Boessenkool  ---
(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

2021-01-13 Thread segher at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

--- Comment #16 from Segher Boessenkool  ---
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

2021-01-05 Thread meissner at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

--- Comment #15 from Michael Meissner  ---
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

2021-01-05 Thread wschmidt at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

--- Comment #14 from Bill Schmidt  ---
I agree, Peter.

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

2021-01-05 Thread bergner at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

--- Comment #13 from Peter Bergner  ---
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

2021-01-05 Thread wschmidt at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

--- Comment #12 from Bill Schmidt  ---
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

2021-01-05 Thread segher at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

--- Comment #11 from Segher Boessenkool  ---
(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

2021-01-05 Thread wschmidt at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

--- Comment #10 from Bill Schmidt  ---
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

2021-01-04 Thread meissner at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

--- Comment #9 from Michael Meissner  ---
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

2021-01-04 Thread segher at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

--- Comment #8 from Segher Boessenkool  ---
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

2021-01-04 Thread munroesj at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

--- Comment #7 from Steven Munroe  ---
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

2021-01-04 Thread segher at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

--- Comment #6 from Segher Boessenkool  ---
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

2021-01-04 Thread munroesj at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

--- Comment #5 from Steven Munroe  ---
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

2021-01-04 Thread segher at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

--- Comment #4 from Segher Boessenkool  ---
"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

2021-01-04 Thread bergner at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

--- Comment #3 from Peter Bergner  ---
(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

2021-01-04 Thread meissner at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

--- Comment #2 from Michael Meissner  ---
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

2021-01-04 Thread bergner at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519

Peter Bergner  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  ---
Steve reported the error and I have confirmed it.  I believe this also fails on
GCC 10 (ie, everywhere POWER10 is supported).