[SystemZ] - Valid instructions are rejected with "%r0 used in an address"

[Quuxplusone]

Bugzilla Link	PR45092
Status	RESOLVED FIXED
Importance	P normal
Reported by	Slavomír Kučera (slavomir.kucera@broadcom.com)
Reported on	2020-03-03 09:58:57 -0800
Last modified on	2020-04-01 02:46:01 -0700
Version	9.0
Hardware	PC All
CC	llvm-bugs@lists.llvm.org, paulsson@linux.vnet.ibm.com, uweigand@de.ibm.com
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also

Inline assembler parser for SystemZ rejects valid instructions when %r0 is used
as an operands.

Examples of this would be:
- basr %r2,%r0
- bsm  %r2,%r0
- lae  %r2,0(%r14,%r0)

https://godbolt.org/z/wY8VqC

- All of these examples are valid and have a use-case,
- GCC accepts them,
- in AR-mode the order of index and base register actually matters (0(%r14,%r0)
operates on primary, 0(%r0,%r14) operates on whatever ar14 points to).
- the instructions can be coded e.g. as templates (like targets for EX/EXRL).

My preferred solution is to just remove the checks in the parser
(SystemZAsmParser.cpp).

[Quuxplusone]

any opinions?

[Quuxplusone]

I think you're right, this should be supported.

I'll have a look.

[Quuxplusone]

Now fixed as c726c920e040.

[Quuxplusone]

Thanks for the fix.

It probably does not have an impact on codegen, but shouldn't
SystemZOperand::print be augmented as well?

[Quuxplusone]

I don't quite see what change to ::print should be necessary, can you elaborate?

As far as I can see, the existing code should handle the cases where Base or Index are specified as %r0 just fine ...

[Quuxplusone]

in the "case KindMem:" branch, the case of zero base register and non-zero index register won't generate the correct output.

[Quuxplusone]

A value of 0 for Op.Base or Op.Index means that there was no register at all specified, it does not mean that %r0 was specified (the latter would be represented by a value of SystemZ::R0D or SystemZ::R0L).

[Quuxplusone]

ok, my mistake.