RWTH Aachen University
- User Since
- Apr 2 2015, 4:52 AM (171 w, 5 d)
@ABataev does this mean that Clang will now require libatomic even if there is no OpenMP atomic construct? I remember documentation saying that the user has to link atomic libraries when needed...
Thu, Jul 12
Wed, Jul 11
I'm still opposed to this, as stated in my many comments. If at all, you need to make sure that this library doesn't rebuild whenever you do an unrelated change to Clang.
Thu, Jul 5
@simoatze you might want to add a bot building the OpenMP runtime upon each commit to make sure there are no regressions like this...
Tue, Jul 3
Thu, Jun 28
This has completely gone under my radar. Be sure to ping changes if there is no review and some reviewers are actively working on other parts of LLVM.
LGTM. These were the section names I suspected, but I wasn't able to verify back then.
Mon, Jun 25
Should ENABLE_PER_TARGET_RUNTIME_DIR be declared at LLVM's top level CMakeLists.txt? If I read the patch correctly, it's in clang so llvm/runtimes/ relies on the default value being OFF (hard to tell because the patch doesn't follow the current layout of the SVN repository but rather a git monorepo?)
Sun, Jun 24
Fri, Jun 22
Sounds good to me, I'll wait for @grokos to take a look.
Tue, Jun 19
A gentle reminder to please subscribe to openmp-commits so that your commits generate mails to the list, thanks.
Jun 17 2018
Due to the lack of replies, I've reverted this change in rL334903 to unbreak my build. Feel free to submit a patch that doesn't regress the build system, thanks.
Jun 12 2018
Jun 11 2018
Jun 8 2018
Jun 7 2018
IMO this goes into the right direction, we should use the fast implementation in libdevice. If LLVM doesn't lower these calls in the NVPTX backend, I think it's ok to use header wrappers as CUDA already does.
Jun 6 2018
Jun 5 2018
Works for me, I'll abandon D47201 if you prefer this.
Jun 4 2018
Jun 3 2018
Superseded by D47691
Jun 2 2018
Jun 1 2018
Hmm, maybe the scope is much larger: I just tried linking an executable that references a declare target function in a shared library. My assumption was that this already works, given that libomptarget's registration functions can be called multiple times. Am I doing something wrong?
This breaks the build if you are not building a 32bit C++ library, that's why I introduced a check for a full C++ program in D23654. I therefore request this change to be reverted, we need to come up with a better solution that correctly works for in-tree builds.
May 31 2018
May 29 2018
May 27 2018
May 25 2018
I'm not sure about this patch: These commands do not install the aliases, they are created in the build directory and may be needed for testing.
You are absolutely right, thanks for spotting this!
May 22 2018
I meant to say that I'm not sure if it's enough to always call __kmpc_for_static_init_4 and friends or if Clang still needs to generate calls to __kmpc_for_static_init_4_simple_spmd and the like if this is proven to be safe.
May 21 2018
May 20 2018
Was the new map interface added to Clang and just missed it?
May 19 2018
Looks like this was added as a "temporary solution" in D8984. Meanwhile the attribute whitelist was merged half a year later (D7802), so maybe we can just get rid of comparing target-cpu and target-features entirely?
May 18 2018
I think that's intended because the generated code might use instructions based on that feature. If we want to ignore that, we could override TargetTransformInfo::areInlineCompatible for NVPTX to only compare target-cpu - but I'm not sure if that is wise...
I don't think this change actually compiles, did it work for you?
May 16 2018
May 15 2018
I've posted D46901 which dynamically checks supported flags, compiles with Clang 3.9 and current trunk and also allows us to enable libomptarget-nvptx by default.
May 14 2018
Nope, I repeatedly expressed concerns about doing this and it was repeatedly discussed, see D14254 around November 21st: