This is an archive of the discontinued LLVM Phabricator instance.

[mips][ias] Make immediate zero synonymous with $zero when parsing registers.
AbandonedPublic

Authored by dsanders on Jan 30 2015, 7:54 AM.

Details

Reviewers
tomatabacu
Summary

The constant zero is now usable wherever a GPR is expected and will be treated as $zero.

This fixes PR22389.

Diff Detail

Event Timeline

dsanders updated this revision to Diff 19037.Jan 30 2015, 7:54 AM
dsanders retitled this revision from to [mips][ias] Make immediate zero synonymous with $zero when parsing registers..
dsanders updated this object.
dsanders edited the test plan for this revision. (Show Details)
dsanders added a reviewer: tomatabacu.
dsanders added subscribers: emaste, Unknown Object (MLST).
tomatabacu accepted this revision.Jan 30 2015, 10:04 AM
tomatabacu edited edge metadata.

I'm not sure if we should do this.
This patch would make us accept very strange instructions, such as "add 0, $4, $4", and it does not address the root of the issue, which is the IAS' lack of a BNE+Imm macro instruction.
GAS has such a macro, so it doesn't complain about Ed's use case (and also accepts any other immediates).

If Ed thinks it would be useful for him to have his particular use case fixed sooner rather than later, then LGTM with the inlined changes.
Otherwise, I think doing a proper implementation of the BNE+Imm macro would be best (which we should do at some point either way).

Also, adding some FIXME's to the source code which mention the BNE+Imm macro would be useful.

lib/Target/Mips/AsmParser/MipsAsmParser.cpp
898–900

Actually, I believe you can do this because you have access to the MipsAsmParser, so you can call AsmParser.isGP64bit().

test/MC/Mips/zero.s
2

Mention that this test is for PR22389.

6–7

Add the example from the Bugzilla ticket (bne $2, 0x0, foo).

This revision is now accepted and ready to land.Jan 30 2015, 10:04 AM

I'm not sure if we should do this.
This patch would make us accept very strange instructions, such as "add 0, $4, $4"

I hadn't thought of that one. I was thinking of things like 'addu $2, 0, $2' and instructions that don't have immediate forms.

I'm a little on the fence as to whether I agree it's strange or not. True, it's syntax that GAS doesn't accept but I like the way it suggests that the result is still zero after the instruction because constants don't change.

and it does not address the root of the issue, which is the IAS' lack of a BNE+Imm macro instruction.
GAS has such a macro, so it doesn't complain about Ed's use case (and also accepts any other immediates).

If Ed thinks it would be useful for him to have his particular use case fixed sooner rather than later, then LGTM with the inlined changes.
Otherwise, I think doing a proper implementation of the BNE+Imm macro would be best (which we should do at some point either way).

You've also touched on another good reason to not do this patch there. If it generates different opcodes compared to the immediate forms of instructions then it will be harder to verify our assembler by comparing object files.

I'm a little on the fence as to whether I agree it's strange or not.

I'm just not keen on introducing such an exception to our handling of the MIPS assembly "type" system.

However, as you yourself have mentioned, there are other stronger reasons to not make this change.

dsanders abandoned this revision.Feb 6 2015, 7:06 AM