This is an archive of the discontinued LLVM Phabricator instance.

Comparing operands should not require the same ValueID
ClosedPublic

Authored by jrkoenig on Aug 24 2015, 4:41 PM.

Details

Summary

When comparing basic blocks, there is an additional check that two
Value*'s should have the same ID, which interferes with merging equivalent
constants of different kinds (such as a ConstantInt and a ConstantPointerNull
in the included testcase). The cmpValues function already ensures that the
two values in each function are the same, so removing this check should not
cause incorrect merging.

Also, the type comparison is redundant, based on reviewing the code and
testing on the test suite and several large LTO bitcodes.

Diff Detail

Repository
rL LLVM

Event Timeline

jrkoenig retitled this revision from to Comparing operands should not require the same ValueID.
jrkoenig updated this object.
jrkoenig added reviewers: jfb, dschuff, nlewycky.
jfb added inline comments.Aug 25 2015, 11:20 AM
test/Transforms/MergeFunc/merge-const-ptr-and-int.ll
2 ↗(On Diff #33022)

Could you add:

  • An equivalent negative test, where i32 and i32* are returned with the same p:64 datalayout. Those shouldn't be merged.
  • A test where ret i64 1 isn't merged with ret i64* null.
  • Test where other equivalent types are merged (vector, array, structure).
  • A test where undef of different types is merged.
  • A test where endianness would be relevant.
4 ↗(On Diff #33022)

"differ"

Added more positive/negative tests.

jfb added inline comments.Aug 25 2015, 1:20 PM
test/Transforms/MergeFunc/merge-const-ptr-and-int.ll
3 ↗(On Diff #33110)

Missing undef and endian.

27 ↗(On Diff #33110)

Here you test A and B funcs by calling them, whereas below you check whether functions are still defined. You should be consistent!

jrkoenig added inline comments.Aug 25 2015, 1:32 PM
test/Transforms/MergeFunc/merge-const-ptr-and-int.ll
3 ↗(On Diff #33110)

Added 1,2, and 3. For 3, only vectors are considered bitcast-able, and thus the mergable.

For 4, this is not possible. In fact, two constants with the same type, one undef and the other not, will not be merged, because they cannot compare equal.

Consider f() { return -1; }, g() { return undef; } and h() { return 1;}. If undef was the same as any constant, the ordering would not be a total order because f == g and g == h, but f < h. In order to handle this, the undef would need to be turned into one of the constants -1 or 1, but it can't be both at once. This would have to be an in-place mutation in the comparison, which is quite ugly.

For 5, I don't think such a thing is possible. The only way endianness can be exposed is by converting a <2x i32> into a < 8 x i8 >, or some other equivalent conversion. This is allowed by cmpConstants. But any extraction from that vector/operation on it will have a different type, and thus compare differently, so practically I doubt you can construct a program which depends on endianess.

jfb added inline comments.Aug 25 2015, 1:38 PM
test/Transforms/MergeFunc/merge-const-ptr-and-int.ll
3 ↗(On Diff #33110)

For undef you can at least merge two functions of different types, but where both are undef?

27 ↗(On Diff #33110)

Missing this :)

Added undef tests; use consistent merge-checking method

Formatting fixups.

jfb edited edge metadata.Aug 25 2015, 1:59 PM

Ugh... sorry for more comments... I think you should separate each test into its own .ll file: as is they check that merging occurred, but the tests doesn't validate *what* got merged! Having them in separate files would make that obvious and potentially catch tricky bugs.

I'm good after that!

test/Transforms/MergeFunc/merge-const-ptr-and-int.ll
2 ↗(On Diff #33116)

Bikeshed: CHECKNOT-NOT is a bit weird. MERGED-NOT would be nicer.

jrkoenig edited edge metadata.

Split tests into different files.

jfb accepted this revision.Aug 25 2015, 2:21 PM
jfb edited edge metadata.

lgtm

This revision is now accepted and ready to land.Aug 25 2015, 2:21 PM
dschuff accepted this revision.Aug 25 2015, 3:23 PM
dschuff edited edge metadata.
This revision was automatically updated to reflect the committed changes.