This is an archive of the discontinued LLVM Phabricator instance.

[GuardWidening] Fix the crash while replacing the users of poison.
ClosedPublic

Authored by skatkov on Apr 3 2023, 2:48 AM.

Details

Summary

When we replace poison with freeze poison it might appear
that user of poison is a constant (for example vector constant).

In this case we will get that constant will get non-constant operand.

Moreover replacing poison and GlobalValue everywhere in module seems
to be overkill. So the solution will be just make a replacement
only in instructions we visited (contributing to hoisted condition).
Moreover if user of posion is constant, this constant also should need
a freeze and it does not make sense to replace poison with frozen version,
just freeze another constant.

Diff Detail

Event Timeline

skatkov created this revision.Apr 3 2023, 2:48 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 3 2023, 2:48 AM
skatkov requested review of this revision.Apr 3 2023, 2:48 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 3 2023, 2:48 AM
mkazantsev accepted this revision.Apr 3 2023, 3:00 AM

Test coverage is weak. Could you please commit more tests where we freeze:

  • a global used in more than one function (to make sure we don't replace with freeze in neighboring functions)
  • an argument

?

Not blocking on this.

llvm/lib/Transforms/Scalar/GuardWidening.cpp
639

[&](const Use &U) { return U.getUser() != FI; });?

This revision is now accepted and ready to land.Apr 3 2023, 3:00 AM
This revision was landed with ongoing or failed builds.Apr 3 2023, 3:21 AM
This revision was automatically updated to reflect the committed changes.
nikic added a subscriber: nikic.Apr 3 2023, 3:32 AM

Walking users of ConstantData is not allowed -- you need to fix this in a way that doesn't perform such a walk in the first place (e.g. by bailing of out of those cases early).

Walking users of ConstantData is not allowed -- you need to fix this in a way that doesn't perform such a walk in the first place (e.g. by bailing of out of those cases early).

will do, need to think, how to handle it.

By the way, where it is prohibited?

nikic added a comment.Apr 3 2023, 7:20 AM

Walking users of ConstantData is not allowed -- you need to fix this in a way that doesn't perform such a walk in the first place (e.g. by bailing of out of those cases early).

will do, need to think, how to handle it.

By the way, where it is prohibited?

See https://discourse.llvm.org/t/rfc-constantdata-should-not-have-use-lists/42606. Unfortunately, the actual assertion to enforce this never landed. It's pretty much always a bug if you do this though, if nothing else because ConstantData can have huge use lists (with millions of uses, including across modules).

Walking users of ConstantData is not allowed -- you need to fix this in a way that doesn't perform such a walk in the first place (e.g. by bailing of out of those cases early).

will do, need to think, how to handle it.

By the way, where it is prohibited?

See https://discourse.llvm.org/t/rfc-constantdata-should-not-have-use-lists/42606. Unfortunately, the actual assertion to enforce this never landed. It's pretty much always a bug if you do this though, if nothing else because ConstantData can have huge use lists (with millions of uses, including across modules).

ok, I see. It makes sense to re-factor this anyway. Traversing all constants and global users is compile time overhead anyway.