Page MenuHomePhabricator

[mips] Tolerate the use of the %z inline asm operand modifier with non-immediates.

Authored by tomatabacu on Oct 29 2014, 4:45 AM.



Currently, we give an error if %z is used with non-immediates, instead of continuing as if the %z isn't there.

For example, you use the %z operand modifier along with the "Jr" constraints ("r" makes the operand a register, and "J" makes it an immediate, but only if its value is 0).
In this case, you want the compiler to print "$0" if the inline asm input operand turns out to be an immediate zero and you want it to print the register containing the operand, if it's not.

We give an error in the latter case, and we shouldn't (GCC also doesn't).

Diff Detail

Event Timeline

tomatabacu updated this revision to Diff 15544.Oct 29 2014, 4:45 AM
tomatabacu retitled this revision from to [mips] Tolerate the use of the %z inline asm operand modifier with non-immediates..
tomatabacu updated this object.
tomatabacu edited the test plan for this revision. (Show Details)
tomatabacu added a reviewer: dsanders.
tomatabacu added a subscriber: Unknown Object (MLST).
dsanders added inline comments.Nov 3 2014, 5:32 AM

$0 shouldn't be permitted


$0 shouldn't be permitted


Shouldn't this be restricted to $0?

dsanders requested changes to this revision.Nov 4 2014, 3:49 AM
dsanders edited edge metadata.
This revision now requires changes to proceed.Nov 4 2014, 3:49 AM
tomatabacu updated this revision to Diff 15767.Nov 4 2014, 7:31 AM
tomatabacu edited edge metadata.

Addressed Daniel's concerns.

tomatabacu added inline comments.Nov 4 2014, 7:34 AM

No, because in this case we no longer have the "J" constraint (which makes zero-values into immediates), so the value is always put into a register.

dsanders accepted this revision.Nov 5 2014, 5:56 AM
dsanders edited edge metadata.

LGTM with a small change so that we have to correct the test once we've fixed the materialization of 0.


The reason I think it should be $0 is that materializing 0 can be done without any code. Whereas the above examples passes in the immediate 0 and printed it as $0, in this code I believe this one should be passing in the register $0.

As we discussed off-list, the code generator is currently materializing 0 with 'addiu $1, $zero, 0'. We need to fix this but it's not related to your patch.

For now, could you add an explicit check for the 'addiu ${{[0-9]+}}, $zero, 0' along with a fixme comment explaining the issue. This way, we will be prompted to correct the test when we fix the materialization problem.

This revision is now accepted and ready to land.Nov 5 2014, 5:56 AM
tomatabacu added inline comments.Nov 6 2014, 2:54 AM

There's no need for an additional check for addiu, as the test would already fail if the materialization of 0 was fixed.
This is because, for the first argument of the mtc0 instruction, we're checking for any register that is not $0, so if the currently non-$0 register changes into $0, the test will fail.

I'll still add a FIXME with an explanation, though.

tomatabacu updated this revision to Diff 15850.Nov 6 2014, 3:26 AM
tomatabacu edited edge metadata.

Added FIXME with explanation, as suggested by Daniel.

dsanders added inline comments.Nov 6 2014, 3:44 AM

Good point. LGTM.

tomatabacu closed this revision.Nov 6 2014, 6:36 AM