This is an archive of the discontinued LLVM Phabricator instance.

[JumpThreading] See through Cast Instructions
ClosedPublic

Authored by haicheng on Feb 26 2016, 4:14 PM.

Details

Summary

Let JumpThreading to thread over blocks like following Merge block

Merge:

%B = phi i32 [0, %Entry], [%v1, %F1]
%N = trunc i32 %B to i1
br i1 %N, label %T2, label %F2

Diff Detail

Repository
rL LLVM

Event Timeline

haicheng updated this revision to Diff 49259.Feb 26 2016, 4:14 PM
haicheng retitled this revision from to [JumpThreading] See through Cast Instructions.
haicheng updated this object.
haicheng added reviewers: mssimpso, gberry, mcrosier, bmakam.
haicheng set the repository for this revision to rL LLVM.
haicheng added a subscriber: llvm-commits.
gberry edited edge metadata.Feb 29 2016, 10:37 AM

Would it not be better to fix SimplifyICmpInst to have some way of returning that it has done some simplification?

Would it not be better to fix SimplifyICmpInst to have some way of returning that it has done some simplification?

I am not sure. Currently, SimplifyICmpInst either return a ConstantInt or an existing value. Is it safe to let it return a new value? Will it break anything?
.
ComputeValueKnownInPredecessors() is very similar to SimplifyInstruction(). Many cases handled in ComputeValueKnownInPredecessors() (e.g., xor 1 x => not x ) are also the targets of SimplifyInstruction(). However, there are still some subtle differences between them (e.g. they treat undef differently) so that we cannot replace one by the other. So, I think it might be better just enhancing ComputeValueKnownInPredecessors().

I see what you're saying, but perhaps a better motivating example would be a case where the zext was of a phi value that was only constant on some paths?
The example (and test) you give above seems more like a phase-ordering issue, since simplifying away the zext completely seems like something that should already be happening outside of JumpThreading.

lib/Transforms/Scalar/JumpThreading.cpp
485

This comment is incorrect, right?

haicheng updated this revision to Diff 49425.Feb 29 2016, 2:19 PM
haicheng edited edge metadata.
haicheng marked an inline comment as done.

Thank you very much, Geoff.

I changed the test case. Please let me know if it is better.

haicheng updated this object.Feb 29 2016, 2:23 PM

Making ComputeValueKnownInPredecessors() recursive for any cast instruction seems like it might be a bit heavy handed. Perhaps you could limit it to casts of phi nodes as is done with CmpInsts farther down to reduce the compile time impact?

Perhaps someone more familiar with this pass (@majnemer, @sanjoy ?) could comment on this?

bmakam edited edge metadata.Mar 1 2016, 12:33 PM

I share the same concern as Geoff. A recursive solution is compile time heavy for catching some corner cases. Most cases will already be handled by SimplifyInst. Do you have any data on how much impact this has on compile times?

haicheng updated this revision to Diff 49678.Mar 2 2016, 3:09 PM
haicheng edited edge metadata.

Only see through Cast when the source is PHI or Cmp, two types of instructions that are most important to JumpThreading. This version makes less changes and takes much less compilation time. The measured compilation time shows the difference is within the noise range.

gberry added a comment.Mar 3 2016, 8:21 AM

Could you limit this a bit further by only looking at phis of type i1?

haicheng updated this revision to Diff 49771.Mar 3 2016, 1:46 PM

Further restricting the source type to be i1 only. Thank you, Geoff.

haicheng updated this revision to Diff 49773.Mar 3 2016, 1:48 PM

Add the diff context.

mcrosier edited edge metadata.Mar 14 2016, 8:59 AM

LGTM, but I'll defer the official accept to @bmakam and/or @gberry as they my have some additional comments.

This LGTM as well, with the one minor comment request.
This code doesn't seem to have an owner, so I don't know if there is someone else who can more authoritatively approve it.

test/Transforms/JumpThreading/basic.ll
514

Can you add a comment explaining what this test is checking for?

mcrosier accepted this revision.Mar 14 2016, 11:02 AM
mcrosier edited edge metadata.

Per Balaram/Geoff. Please add a comment to the test case.

This revision is now accepted and ready to land.Mar 14 2016, 11:02 AM
haicheng updated this revision to Diff 50674.Mar 14 2016, 4:51 PM
haicheng edited edge metadata.
haicheng marked an inline comment as done.

Add a test case comment. I will land it soon.

haicheng closed this revision.Mar 17 2016, 2:54 PM

landed in r263618.