This is an archive of the discontinued LLVM Phabricator instance.

[BitcodeReader] Infer the correct runtime preemption for GlobalValue
ClosedPublic

Authored by steven_wu on Jul 6 2018, 1:36 PM.

Details

Summary

To allow bitcode built by old compiler to pass the current verifer,
BitcodeReader needs to auto infer the correct runtime preemption from
linkage and visibility for GlobalValues.

Since llvm-6.0 bitcode already contains the new field but can be
incorrect in some cases, the attribute needs to be recomputed all the
time in BitcodeReader. This will make all the GVs has dso_local marked
correctly if read from bitcode, and it should still allow the verifier
to catch mistakes in optimization passes.

This should fix PR38009.

Diff Detail

Repository
rL LLVM

Event Timeline

steven_wu created this revision.Jul 6 2018, 1:36 PM
vsk added a comment.Jul 6 2018, 2:20 PM

Thanks for doing this!

Could you add a test? Adding "opt -verify <old-bitcode-file>" run lines to the compatibility tests would be fine.

lib/Bitcode/Reader/BitcodeReader.cpp
2927 ↗(On Diff #154449)

Could you factor this out into a helper which accepts a GlobalValue &?

In D49039#1154801, @vsk wrote:

Thanks for doing this!

Could you add a test? Adding "opt -verify <old-bitcode-file>" run lines to the compatibility tests would be fine.

You will be surprise how many things will break if you run verifier on old bitcode file. The first error you will hit is not about dso_local: Global is marked as dllimport, but not external

vsk added a comment.Jul 6 2018, 3:31 PM
In D49039#1154801, @vsk wrote:

Thanks for doing this!

Could you add a test? Adding "opt -verify <old-bitcode-file>" run lines to the compatibility tests would be fine.

You will be surprise how many things will break if you run verifier on old bitcode file. The first error you will hit is not about dso_local: Global is marked as dllimport, but not external

In that case, we can enable verification on checked-in bitcode files as a follow-up. How about testing this by round-tripping textual IR through llvm-as and llvm-dis? You just need a function, alias, and global var with local linkage and without dso_local set, right?

In that case, we can enable verification on checked-in bitcode files as a follow-up. How about testing this by round-tripping textual IR through llvm-as and llvm-dis? You just need a function, alias, and global var with local linkage and without dso_local set, right?

Nope. dso_local is even implicit in assembly which is a completely different from bitcode reader/writer.

static void PrintDSOLocation(const GlobalValue &GV,
                             formatted_raw_ostream &Out) {
  // GVs with local linkage or non default visibility are implicitly dso_local,
  // so we don't print it.
  bool Implicit = GV.hasLocalLinkage() ||
                  (!GV.hasExternalWeakLinkage() && !GV.hasDefaultVisibility());
  if (GV.isDSOLocal() && !Implicit)
    Out << "dso_local ";
}

I guess this patch is unifying the behavior, sort of.

steven_wu updated this revision to Diff 154469.Jul 6 2018, 4:06 PM

Address review feedback

steven_wu marked an inline comment as done.Jul 6 2018, 4:06 PM
vsk added a comment.Jul 6 2018, 4:12 PM

In that case, we can enable verification on checked-in bitcode files as a follow-up. How about testing this by round-tripping textual IR through llvm-as and llvm-dis? You just need a function, alias, and global var with local linkage and without dso_local set, right?

Nope. dso_local is even implicit in assembly which is a completely different from bitcode reader/writer.

static void PrintDSOLocation(const GlobalValue &GV,
                             formatted_raw_ostream &Out) {
  // GVs with local linkage or non default visibility are implicitly dso_local,
  // so we don't print it.
  bool Implicit = GV.hasLocalLinkage() ||
                  (!GV.hasExternalWeakLinkage() && !GV.hasDefaultVisibility());
  if (GV.isDSOLocal() && !Implicit)
    Out << "dso_local ";
}

I guess this patch is unifying the behavior, sort of.

Hm, if there's no simpler option, what about checking in bitcode produced by 6.0 which would have triggered the verifier?

steven_wu updated this revision to Diff 154480.Jul 6 2018, 7:20 PM

Add testcase using 6.0 bitcode.

Thanks for doing this!

vsk accepted this revision.Jul 9 2018, 9:51 AM

Thanks, LGTM!

This revision is now accepted and ready to land.Jul 9 2018, 9:51 AM
This revision was automatically updated to reflect the committed changes.