This is an archive of the discontinued LLVM Phabricator instance.

[mlir] Remove need for static global ctors from mlir-translate
ClosedPublic

Authored by jroelofs on Apr 5 2020, 1:55 PM.

Diff Detail

Event Timeline

jroelofs created this revision.Apr 5 2020, 1:55 PM

This is great. I also just sent out https://reviews.llvm.org/D77514 to clean up the internal registration facilities.

mehdi_amini accepted this revision.Apr 5 2020, 2:06 PM
This revision is now accepted and ready to land.Apr 5 2020, 2:06 PM
rriddle accepted this revision.Apr 5 2020, 2:06 PM

Thanks for doing this, it will definitely simplify many things about the way linkage is done.

mlir/include/mlir/InitAllTranslations.h
31

nit: "init_once" is a little misleading, since this doesn't actually ensure that.

mlir/test/EDSC/CMakeLists.txt
24–30

Please verify these changes with BUILD_SHARED_LIBS=on. It should have been the case that the whole_archive_link an link_libraries were mutually exclusive, so I'd expect that all of these need to go in a target_link_libraries instead.

jroelofs updated this revision to Diff 255199.Apr 5 2020, 2:19 PM

clang-format

jroelofs marked 2 inline comments as done.Apr 5 2020, 2:28 PM
jroelofs added inline comments.
mlir/include/mlir/InitAllTranslations.h
31

Thought that was guaranteed with this pattern C++. What case am I missing?

If multiple threads attempt to initialize the same static local variable concurrently, the initialization occurs exactly once

https://en.cppreference.com/w/cpp/language/storage_duration#Static_local_variables

mlir/test/EDSC/CMakeLists.txt
24–30

BUILD_SHARED_LIBS=ON

Currently building that config again. That that fell over is what led me down this rabbit hole in the first place :)

I'd expect that all of these need to go in a target_link_libraries instead.

Unless I misunderstood, they're there already.

jroelofs marked an inline comment as done and an inline comment as not done.Apr 5 2020, 2:42 PM
jroelofs added inline comments.
mlir/test/EDSC/CMakeLists.txt
24–30

BUILD_SHARED_LIBS=ON

Good call. This broke a bunch of test runners. Investigating.

mlir/include/mlir/InitAllTranslations.h
31

You're right.. I misparsed the code when I scanned it.

jroelofs updated this revision to Diff 255460.Apr 6 2020, 1:14 PM
jroelofs marked an inline comment as not done.

I tried this out with BUILD_SHARED_LIBS=ON, and unfortunately ran into a problem with the way this custom rtti behaves across dso's:

https://github.com/llvm/llvm-project/blob/549e87f3d04bbae91bc7bc38609ce7073e2c8a6d/mlir/include/mlir/Support/STLExtras.h#L101

That variable gets marked dso_local even if the function is inline, meaning that different instances of it in each shared lib have different addresses, breaking the traits implementation.

Discussion on Discord pointed at this thread, which has more info: https://llvm.discourse.group/t/shared-library-support/381/5

Should fixing that be a blocker to landing this patch?

If not, should we have a top-level message indicating that it doesn't work (yet)?

if(BUILD_SHARED_LIBS)
  message(WARNING "This isn't going to behave well at runtime")
endif()
rriddle added inline comments.Apr 6 2020, 10:05 PM
mlir/lib/Dialect/SPIRV/Serialization/TranslateRegistration.cpp
72

Please remove the extra semicolon here.

I patched this locally and tried to build with BUILD_SHARED_LIBS=ON but the tests are passing for me? Anything specific to configure?

Interestingly I reproduce on MacOS but not on Linux

jroelofs updated this revision to Diff 255681.Apr 7 2020, 8:20 AM

review feedback: drop semicolon

jroelofs updated this revision to Diff 255683.Apr 7 2020, 8:24 AM

test update: trying out arcanist

jroelofs marked 3 inline comments as done and an inline comment as not done.Apr 7 2020, 8:25 AM
Harbormaster completed remote builds in B52157: Diff 255681.

I tried this out with BUILD_SHARED_LIBS=ON, and unfortunately ran into a problem with the way this custom rtti behaves

snip

Should fixing that be a blocker to landing this patch?

Per discussion on Discord, I'll land this patch without solving that, since it's an incremental improvement and doesn't regress the behavior here.