This is an archive of the discontinued LLVM Phabricator instance.

[llvm] Assert two ValIDs are the same kind before comparing
ClosedPublic

Authored by leonardchan on Sep 22 2022, 3:16 PM.

Details

Summary

I suspect the reason for why D134234 was failing sometimes is because "operator<" for a ValID could compare ValIDs of different kinds but have the same non-active values and return an incorrect result. This is an issue if I attempt to store ValIDs of different kinds in an std::map but we compare different "active" values. For example, if I create an std::map and store some ValIDs of kind t_GlobalName, then I insert a ValID of kind t_GlobalID, the current "operator<" will see that one of the operands is a t_GlobalID and compare it against the UIntVal of other items in the map, but the other items in the map don't set UIntVal because they're not t_GlobalIDs, so I compare against a dummy/uninitialized value.

It seems pretty easy to add mixed ValID kinds into an std::map in LLParser, so this just asserts that when doing the comparison that both ValIDs are the same kind.

Diff Detail

Event Timeline

leonardchan created this revision.Sep 22 2022, 3:16 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 22 2022, 3:16 PM
Herald added a subscriber: StephenFan. · View Herald Transcript
leonardchan requested review of this revision.Sep 22 2022, 3:16 PM

Locally I can assert none of the current llvm tests fail with this in a debug build.

Alternative approaches are just adding another branch that compares the kinds:

bool operator<(const ValID &RHS) const {
  if (Kind != RHS.Kind) return Kind < RHS.Kind;
...

or updating the ValID layout to hide members behind getters/setters that assert the correct kind.

phosek accepted this revision.Sep 22 2022, 3:29 PM

Locally I can assert none of the current llvm tests fail with this in a debug build.

Alternative approaches are just adding another branch that compares the kinds:

bool operator<(const ValID &RHS) const {
  if (Kind != RHS.Kind) return Kind < RHS.Kind;
...

or updating the ValID layout to hide members behind getters/setters that assert the correct kind.

I think that asserting the invariant is an improvement regardless of whether we decide to add the comparison later or not.

This revision is now accepted and ready to land.Sep 22 2022, 3:29 PM