This is an archive of the discontinued LLVM Phabricator instance.

[PowerPC] Fix the spill issue exposed by r310809
ClosedPublic

Authored by nemanjai on Sep 19 2017, 2:04 PM.

Details

Summary

When I committed r310809, I didn't realize that it exposed a bug in the compare lowering I committed previously. Namely the issue is that compares of i32 values used code that produces 64-bit immediate results. When the register allocator spilled one of those intermediate values, it would spill/reload it as a 32-bit value. The sign bits are then lost and the comparison produces incorrect results.

This patch is basically r310809 but with the addition of the fix for the spilling issue. Namely, we now ensure that if the intermediate results are 64-bit values, the value is changed to an i64 so that it is spilled/reloaded as a 64-bit entity.

Diff Detail

Repository
rL LLVM

Event Timeline

nemanjai created this revision.Sep 19 2017, 2:04 PM
nemanjai updated this revision to Diff 116091.Sep 20 2017, 3:22 PM
nemanjai retitled this revision from [PowerPC] Reimplement r310809 with fix for the spill issue to [PowerPC] Fix the spill issue exposed by r310809.

Updated the patch to only include the bug fix that r310809 needs in order to function correctly. This won't apply cleanly to trunk because r310809 was pulled out, so this needs to apply on top of that.

nemanjai updated this revision to Diff 116108.Sep 20 2017, 4:09 PM

Add a test case.

hfinkel edited edge metadata.Sep 21 2017, 9:15 AM

I think this generally looks fine.

Just as a general note on code organizations and commenting, we seem to be accumulating a pretty deep call tree here of functions that only work correctly in 64-bit mode. Not in this patch, but we should do something about this (either segregating these things into a distinct part of the file and/or adding asserts and/or comments to the 64-bit-mode-only functions.

echristo accepted this revision.Sep 21 2017, 6:20 PM

I think this generally looks fine.

Just as a general note on code organizations and commenting, we seem to be accumulating a pretty deep call tree here of functions that only work correctly in 64-bit mode. Not in this patch, but we should do something about this (either segregating these things into a distinct part of the file and/or adding asserts and/or comments to the 64-bit-mode-only functions.

Agreed. Also a lot of the fine points of when to extend and when not could probably be split out as well. This is definitely getting pretty unwieldy.

-eric

lib/Target/PowerPC/PPCISelDAGToDAG.cpp
2979–2983

As a note I find the ZeroCompare enum to be fairly inscrutable. Perhaps document it and what each value is?

This revision is now accepted and ready to land.Sep 21 2017, 6:20 PM

I think this generally looks fine.

Just as a general note on code organizations and commenting, we seem to be accumulating a pretty deep call tree here of functions that only work correctly in 64-bit mode. Not in this patch, but we should do something about this (either segregating these things into a distinct part of the file and/or adding asserts and/or comments to the 64-bit-mode-only functions.

Agreed. Also a lot of the fine points of when to extend and when not could probably be split out as well. This is definitely getting pretty unwieldy.

-eric

OK. I'll commit this patch as-is with the inline comment addressed.

Then perhaps in a subsequent patch, I'll create something like class GPRComparisonSelector that uses essentially the same approach as the BitPermutationSelector. The Select() function will do the necessary checks and exit early if we're not a PPC64 target. All the functions that do the actual selection will be private. This way we should be able to avoid carelessly calling these functions under invalid conditions.
Does that sound like a good plan?

lib/Target/PowerPC/PPCISelDAGToDAG.cpp
2979–2983

Will do.

This revision was automatically updated to reflect the committed changes.

I think this generally looks fine.

Just as a general note on code organizations and commenting, we seem to be accumulating a pretty deep call tree here of functions that only work correctly in 64-bit mode. Not in this patch, but we should do something about this (either segregating these things into a distinct part of the file and/or adding asserts and/or comments to the 64-bit-mode-only functions.

Agreed. Also a lot of the fine points of when to extend and when not could probably be split out as well. This is definitely getting pretty unwieldy.

-eric

OK. I'll commit this patch as-is with the inline comment addressed.

Then perhaps in a subsequent patch, I'll create something like class GPRComparisonSelector that uses essentially the same approach as the BitPermutationSelector. The Select() function will do the necessary checks and exit early if we're not a PPC64 target. All the functions that do the actual selection will be private. This way we should be able to avoid carelessly calling these functions under invalid conditions.
Does that sound like a good plan?

Yes, I think that would be better.