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
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
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
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
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
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:
>
> ---
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.
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=edit
Example code for both input and output %m usage
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 =
int get (void)
{
int a;
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
Michael Meissner changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|meissner at
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!)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
Michael Meissner changed:
What|Removed |Added
Status|NEW |ASSIGNED
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #18
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).
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #14 from Bill Schmidt ---
I agree, Peter.
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
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
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?
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.
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
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").
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.
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.
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
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).
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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
34 matches
Mail list logo
