This is an archive of the discontinued LLVM Phabricator instance.

[ValueTracking, BasicAA] Don't simplify instructions
ClosedPublic

Authored by nikic on Jun 20 2020, 8:41 AM.

Details

Summary

GetUnderlyingObject() (and by required symmetry DecomposeGEPExpression()) will call SimplifyInstruction on the passed value if other checks fail. This simplification is very expensive, but has little effect in practice. This patch removes the SimplifyInstruction call, and replaces it with a check for single-argument phis (which can occur in canonical IR in LCSSA form), which is the only useful simplification case I was able to identify.

Compile-time numbers: http://llvm-compile-time-tracker.com/compare.php?from=be93ba1fd608cf9bef0a414c3193dff398c80c44&to=38bd3bc987b0c0f2e715859c78cd705e05689534&stat=instructions At O3 the geomean improvement is -1.7%. The largest improvement is SPASS with ThinLTO at -6%.

In test-suite, I see only two tests with a hash difference and no code size difference (PAQ8p, Ptrdist), which indicates that the simplification only ends up being useful very rarely. (I would have liked to figure out which simplification is responsible here, but wasn't able to spot it looking at transformation logs.)

Diff Detail

Event Timeline

nikic created this revision.Jun 20 2020, 8:41 AM
nikic marked an inline comment as done.Jun 20 2020, 8:48 AM
nikic added inline comments.
llvm/test/CodeGen/AMDGPU/promote-alloca-to-lds-select.ll
78

Let me explain what is going on here: We have selects on undefs involved here, which means that instruction simplification will simplify to the first select operand. If a real condition is used, then that of course doesn't happen. Because of that, this test is not testing anything useful right now.

In fact, I think this indicates that the current usage of SimplifyInstruction inside GetUnderlyingObject may be subtly unsound. GetUnderlyingObject will declare that the first select operand is the underlying object, but other code is permitted to later simplify that select to the second operand instead. In this case optimizations may have been performed based on an incorrect assumption. (While undef can be true or false, it cannot be both at the same time.)

efriedma accepted this revision.Jun 20 2020, 1:26 PM
efriedma added a subscriber: efriedma.

LGTM

llvm/test/CodeGen/AMDGPU/promote-alloca-to-lds-select.ll
78
This revision is now accepted and ready to land.Jun 20 2020, 1:26 PM
hfinkel accepted this revision.Jun 20 2020, 4:00 PM
hfinkel added a subscriber: hfinkel.

LGTM too.

This revision was automatically updated to reflect the committed changes.