This is an archive of the discontinued LLVM Phabricator instance.

[PPC64] Properly handle the mftb instruction
ClosedPublic

Authored by kbarton on Jun 12 2015, 2:18 PM.

Details

Summary

The mftb instruction was incorrectly marked as deprecated in the PPC Backend. Instead, it should not be treated as deprecated, but rather be implemented using the mfspr instruction. A similar patch was put into GCC last year. Details can be found at:

https://sourceware.org/ml/binutils/2014-11/msg00383.html.

This change will replace instances of the mftb instruction with the mfspr instruction for all CPUs except 601 and pwr3. This will also be the default behaviour.

Additional details can be found in:

https://llvm.org/bugs/show_bug.cgi?id=23680

Diff Detail

Event Timeline

kbarton updated this revision to Diff 27594.Jun 12 2015, 2:18 PM
kbarton retitled this revision from to [PPC64] Properly handle the mftb instruction.
kbarton updated this object.
kbarton edited the test plan for this revision. (Show Details)
kbarton added a subscriber: Unknown Object (MLST).
nemanjai added inline comments.Jun 13 2015, 6:33 AM
lib/Target/PowerPC/AsmParser/PPCAsmParser.cpp
1189

I am probably missing something since the test case you have does test the mnemonic with a single operand, but I'm curious how come we don't throw this assert when processing lines 50 and 61 in the test case. Does the immediate operand get added to the DAG before this?

1195

I'm just curious about why the temp is needed. From the standpoint of readability, it would seem to make sense to call

Inst.setOpcode(PPC::MFSPR);

then the remaining modification and copy-assignment is not necessary. Unless of course there is a reason the temporary is needed (i.e. Inst is of a type that does not have setOpcode, etc.).

lib/Target/PowerPC/PPC.td
250

This is really nit-picking, but leaving the name the same seems misleading. We are essentially "un-deprecating" the instruction and adding the DeprecatedMFTB to almost every processor.
I do realize that the instruction itself will not be emitted, but a different mnemonic, but this may not be clear to someone looking at this 5 years from now.

wschmidt edited edge metadata.Jun 15 2015, 11:01 AM

Looks good to me with identified changes.

lib/Target/PowerPC/AsmParser/PPCAsmParser.cpp
1188

Since we are no longer considering this to be deprecated, I think we should change the name of the bit to FeatureMFTB.

1195

Agree with Nemanja here.

lib/Target/PowerPC/PPC.td
250

Ah, I see Nemanja had the same concern.

kbarton added inline comments.Jun 15 2015, 12:06 PM
lib/Target/PowerPC/AsmParser/PPCAsmParser.cpp
1188

OK, I will change the name to FeatureMFTB

1189

This is handled by the instruction aliases that were added for the mftb instruction.
I added the assert initially to ensure that was happening correctly, and then decided to leave it since I don't think it will hurt anything. If for some reason those aliases are removed, this code will fail somehow (hopefully at compile time) because you are accessing an operand that doesn't exist. Worst case that access is allowed, somehow, and we end up with incorrect code generated. The assert should prevent identify all of those cases.

1195

I'm following the convention that was used in all the other cases. I don't know if there are side effects of changing operands in place. I don't really see the disadvantage of doing it this way - the extra copy introduced by the temp is negligible in the grand scheme of things.

kbarton accepted this revision.Jun 16 2015, 9:05 AM
kbarton added a reviewer: kbarton.
This revision is now accepted and ready to land.Jun 16 2015, 9:05 AM
kbarton closed this revision.Jun 16 2015, 9:06 AM

Committed revision 239827.