Closed Quuxplusone closed 4 years ago
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 |
any opinions?
I think you're right, this should be supported.
I'll have a look.
Now fixed as c726c920e040.
Thanks for the fix.
It probably does not have an impact on codegen, but shouldn't
SystemZOperand::print be augmented as well?
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 ...
in the "case KindMem:" branch, the case of zero base register and non-zero index register won't generate the correct output.
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).
ok, my mistake.