Hahnfeld (Jonas Hahnfeld)
User

Projects

User does not belong to any projects.

User Details

User Since
Apr 2 2015, 4:52 AM (171 w, 5 d)
RWTH Aachen University

Recent Activity

Yesterday

Hahnfeld added a comment to D49386: Make tests unsupported if libatomic cannot be found..

@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...

Mon, Jul 16, 11:22 AM
Hahnfeld added a comment to D49386: Make tests unsupported if libatomic cannot be found..

@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...

Mon, Jul 16, 11:03 AM

Thu, Jul 12

Hahnfeld added a comment to D46842: [OpenMP][libomptarget] Make bitcode library building depend on clang and llvm-linker being available .

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.

I think that we should do the same thing here as we do with other things that are built with the just-built Clang (to be consistent with everything). By this metric, how does this compare?

Thu, Jul 12, 7:41 AM

Wed, Jul 11

Hahnfeld requested changes to D46842: [OpenMP][libomptarget] Make bitcode library building depend on clang and llvm-linker being available .

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.

Wed, Jul 11, 10:59 PM
Hahnfeld added inline comments to D49188: [OpenMP] Initialize data sharing stack for SPMD case.
Wed, Jul 11, 8:25 AM

Thu, Jul 5

Hahnfeld added a comment to D48888: Dropped non-supoorted "--no-as-needed" flag from OMPT tests for macOS.

@simoatze you might want to add a bot building the OpenMP runtime upon each commit to make sure there are no regressions like this...

Thu, Jul 5, 2:14 AM

Tue, Jul 3

Hahnfeld added a comment to D48888: Dropped non-supoorted "--no-as-needed" flag from OMPT tests for macOS.

As discussed on the mailing list, the flag should only be dropped on Mac OS. My pragmatic solution would be:

if config.operating_system == 'Darwin':
    config.substitutions.append(("--Wl,--no-as-needed", ""))

Not sure what @Hahnfeld thinks about this solution :)

The cleaner solution would probably be to define a %no-as-needed-flag substitution.

Tue, Jul 3, 12:55 PM

Thu, Jun 28

Hahnfeld added a comment to D44522: [Libomptarget] Full implementation of the target-offload-icv.

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.

Thu, Jun 28, 7:54 AM · Restricted Project
Hahnfeld accepted D48615: [CUDA] Place all CUDA sections in __NV_CUDA segment on Mac..

LGTM. These were the section names I suspected, but I wasn't able to verify back then.

Thu, Jun 28, 7:34 AM

Mon, Jun 25

Hahnfeld added a comment to D47169: [CMake] Use a different source depending on C++ support.

There's another solution that's simpler than the two mentioned above which would be to simply avoid using the compiler-rt logic for determining the set of supported targets and instead rely on CMake which is already what runtimes/ build does except for the host (it's the COMPILER_RT_DEFAULT_TARGET_ONLY option). I know which targets I want to build runtimes for, I don't want CMake to go on and try guessing which targets my compiler may or may not support. This needs D45604 but that change is ready to land so I might try and go with that approach.

Mon, Jun 25, 1:38 AM
Hahnfeld added a comment to D45604: Support for multiarch runtimes layout.

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?)

Mon, Jun 25, 1:35 AM

Sun, Jun 24

Hahnfeld added a comment to D47169: [CMake] Use a different source depending on C++ support.

I never got any email, sorry about the lack of the response, I just noticed this because your revert broke our build.

Sun, Jun 24, 11:36 PM

Fri, Jun 22

Hahnfeld added a comment to D48480: [OPENMP, NVPTX] Fixes for NVPTX RTL.

Sounds good to me, I'll wait for @grokos to take a look.

Fri, Jun 22, 10:17 AM
Hahnfeld added inline comments to D48480: [OPENMP, NVPTX] Fixes for NVPTX RTL.
Fri, Jun 22, 9:24 AM
Hahnfeld added inline comments to D48480: [OPENMP, NVPTX] Fixes for NVPTX RTL.
Fri, Jun 22, 9:14 AM

Tue, Jun 19

Hahnfeld committed rOMP335069: Remove liboffload from repository.
Remove liboffload from repository
Tue, Jun 19, 12:13 PM
Hahnfeld committed rL335069: Remove liboffload from repository.
Remove liboffload from repository
Tue, Jun 19, 12:13 PM
Hahnfeld added a comment to D48286: [OpenMP] [CUDA] Expose teamid to the debug path.

A gentle reminder to please subscribe to openmp-commits so that your commits generate mails to the list, thanks.

Tue, Jun 19, 10:16 AM · Restricted Project

Jun 17 2018

Hahnfeld committed rL334904: [NVPTX] Ignore target-cpu and -features for inlining.
[NVPTX] Ignore target-cpu and -features for inlining
Jun 17 2018, 2:59 AM
Hahnfeld closed D47691: [NVPTX] Ignore target-cpu and -features for inling.
Jun 17 2018, 2:59 AM
Hahnfeld added a comment to D47169: [CMake] Use a different source depending on C++ support.

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 17 2018, 2:57 AM
Hahnfeld committed rL334903: Revert "[CMake] Use a different source depending on C++ support".
Revert "[CMake] Use a different source depending on C++ support"
Jun 17 2018, 2:56 AM
Hahnfeld committed rCRT334903: Revert "[CMake] Use a different source depending on C++ support".
Revert "[CMake] Use a different source depending on C++ support"
Jun 17 2018, 2:56 AM

Jun 12 2018

Hahnfeld added a comment to D47691: [NVPTX] Ignore target-cpu and -features for inling.

Bottom line -- the situation is far from perfect, but IMO the patch does sensible thing if we're compiling IR with mixed target-cpu and target-features attributes using NVPTX.

In summary, I think that's okay so long as there aren't intrinsics that depend on target features.

Jun 12 2018, 9:10 AM

Jun 11 2018

Hahnfeld added a comment to D47169: [CMake] Use a different source depending on C++ support.

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.

Jun 11 2018, 11:19 AM

Jun 8 2018

Hahnfeld committed rC334281: [CUDA] Fix emission of constant strings in sections.
[CUDA] Fix emission of constant strings in sections
Jun 8 2018, 4:21 AM
Hahnfeld committed rL334281: [CUDA] Fix emission of constant strings in sections.
[CUDA] Fix emission of constant strings in sections
Jun 8 2018, 4:21 AM
Hahnfeld closed D47902: [CUDA] Fix emission of constant strings in sections.
Jun 8 2018, 4:21 AM

Jun 7 2018

Hahnfeld created D47902: [CUDA] Fix emission of constant strings in sections.
Jun 7 2018, 12:41 PM
Hahnfeld added a comment to D47849: [OpenMP][Clang][NVPTX] Enable math functions called in an OpenMP NVPTX target device region to be resolved as device-native function calls.

It's precisely the issue which you report here. Since you don't use device specific math functions, you can run into the problem where you may end up calling assembly instructions for a different architecture. I may have mis-classified this as a correctness issue.

Jun 7 2018, 7:39 AM
Hahnfeld added a comment to D47849: [OpenMP][Clang][NVPTX] Enable math functions called in an OpenMP NVPTX target device region to be resolved as device-native function calls.

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 7 2018, 1:34 AM

Jun 6 2018

Hahnfeld added a comment to D47709: [OMPT] Fix OMPT callbacks for the taskloop construct and add testcase.

Use tc for the iteration count

Jun 6 2018, 6:06 AM
Hahnfeld added inline comments to D47717: [OMPT] Make sure that OMPT is enabled in runtime entry points that access internals of the runtime.
Jun 6 2018, 5:12 AM
Hahnfeld added a comment to D47394: [OpenMP][Clang][NVPTX] Replace bundling with partial linking for the OpenMP NVPTX device offloading toolchain.
In D47394#1123044, @tra wrote:

While I'm not completely convinced that [fatbin]->.c->[clang]->.o (with device code only)->[ld -r] -> host.o (host+device code) is ideal (things could be done with smaller number of tool invocations), it should help to deal with -rdc compilation until we get a chance to improve support for it in Clang. We may revisit and change this portion of the pipeline when clang can incorporate -rdc GPU binaries in a way compatible with CUDA tools.

Jun 6 2018, 3:23 AM

Jun 5 2018

Hahnfeld abandoned D47201: [CUDA] Implement nv_weak attribute for functions.

See D47804

Jun 5 2018, 11:48 PM
Hahnfeld accepted D47804: [CUDA] Replace 'nv_weak' attributes in CUDA headers with 'weak'..

Works for me, I'll abandon D47201 if you prefer this.

Jun 5 2018, 11:47 PM
Hahnfeld added inline comments to D47691: [NVPTX] Ignore target-cpu and -features for inling.
Jun 5 2018, 12:42 PM

Jun 4 2018

Hahnfeld added inline comments to D47717: [OMPT] Make sure that OMPT is enabled in runtime entry points that access internals of the runtime.
Jun 4 2018, 7:26 AM

Jun 3 2018

Hahnfeld abandoned D47070: [CUDA] Upgrade linked bitcode to enable inlining.

Superseded by D47691

Jun 3 2018, 12:15 PM
Hahnfeld created D47691: [NVPTX] Ignore target-cpu and -features for inling.
Jun 3 2018, 12:15 PM
Hahnfeld added a comment to D47394: [OpenMP][Clang][NVPTX] Replace bundling with partial linking for the OpenMP NVPTX device offloading toolchain.

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?

I believe this is a limitation coming from the Cuda toolchain. Not even nvcc supports this case: https://stackoverflow.com/questions/35897002/cuda-nvcc-building-chain-of-libraries

Jun 3 2018, 11:09 AM

Jun 2 2018

Hahnfeld added a comment to D47201: [CUDA] Implement nv_weak attribute for functions.
In D47201#1119249, @tra wrote:

IIUIC, nv_weak is a synonym for weak (<rant>why, oh why did they need it?</rant>)
You may need to hunt down and change few other places that deal with the weak attribute.
E.g.: https://github.com/llvm-project/llvm-project-20170507/blob/master/clang/lib/AST/Decl.cpp#L4267
https://github.com/llvm-project/llvm-project-20170507/blob/master/clang/lib/CodeGen/ItaniumCXXABI.cpp#L3045

If it is truly a synonym for weak, then a better implementation would be to make no semantic distinction between the two attributes -- just add new spellings to weak. If you need to make minor distinctions between the spellings, you can do it using accessors on the attribute.

Jun 2 2018, 3:21 AM

Jun 1 2018

Hahnfeld added a comment to D47394: [OpenMP][Clang][NVPTX] Replace bundling with partial linking for the OpenMP NVPTX device offloading toolchain.

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?

Jun 1 2018, 8:04 AM
Hahnfeld committed rL333757: [OpenMP] Fix typo in NVPTX linker, NFC..
[OpenMP] Fix typo in NVPTX linker, NFC.
Jun 1 2018, 7:48 AM
Hahnfeld committed rC333757: [OpenMP] Fix typo in NVPTX linker, NFC..
[OpenMP] Fix typo in NVPTX linker, NFC.
Jun 1 2018, 7:47 AM
Hahnfeld added a comment to D47394: [OpenMP][Clang][NVPTX] Replace bundling with partial linking for the OpenMP NVPTX device offloading toolchain.
I'm surprised you now disagree with this technique, when I first introduced you to this in an e-mail off list you agreed with it.
Jun 1 2018, 7:18 AM
Hahnfeld updated subscribers of D47169: [CMake] Use a different source depending on C++ support.

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.

Jun 1 2018, 1:56 AM

May 31 2018

Hahnfeld added a comment to D47070: [CUDA] Upgrade linked bitcode to enable inlining.
In D47070#1108803, @tra wrote:

Here's my understanding of what happens:
We've started adding target-features and target-cpu to everything clang generates.
We also need to link with libdevice (or IR generated by clang which which has functions w/o those attributes. Or we need to link with IR produced by clang which used different CUDA SDK and thus different PTX version in target-feature.
Due to attribute mismatch we are failing to inline some of the functions and that hurts performance.

May 31 2018, 11:28 PM
Hahnfeld added a comment to D47201: [CUDA] Implement nv_weak attribute for functions.

Ping

May 31 2018, 10:58 PM
Hahnfeld added a comment to D47394: [OpenMP][Clang][NVPTX] Replace bundling with partial linking for the OpenMP NVPTX device offloading toolchain.

The error is related to lack of device linking, just like you explained two paragraphs down. This is the error I get:

main.o: In function `__cuda_module_ctor':
main.cu:(.text+0x674): undefined reference to `__cudaRegisterLinkedBinary__nv_c5b75865'
May 31 2018, 10:45 PM
Hahnfeld added a comment to D47224: [cmake] Guard another instance where symlinks are being created.

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.

This should be NFC as by default that flag would be ON. I see it being used in lines 306-314 which is dealing with installing the symlinks. Maybe this is just duplicate code.

May 31 2018, 10:38 PM

May 29 2018

Hahnfeld added a comment to D47394: [OpenMP][Clang][NVPTX] Replace bundling with partial linking for the OpenMP NVPTX device offloading toolchain.
In D47394#1115086, @tra wrote:

On one hand I can see how being able to treat GPU-side binaries as any other host files is convenient. On the other hand, this convenience comes with the price of targeting only NVPTX. This seems contrary to OpenMP's goal of supporting many different kinds of accelerators. I'm not sure what's the consensus in the OpenMP community these days, but I vaguely recall that generic bundling/unbundling was explicitly chosen over vendor-specific encapsulation in host .o when the bundling was implemented. If the underlying reasons have changed since then it would be great to hear more details about that.

May 29 2018, 11:46 AM

May 27 2018

Hahnfeld committed rOMP333361: [OMPT] Fix test parallel/not_enough_threads.c.
[OMPT] Fix test parallel/not_enough_threads.c
May 27 2018, 10:13 AM
Hahnfeld committed rL333361: [OMPT] Fix test parallel/not_enough_threads.c.
[OMPT] Fix test parallel/not_enough_threads.c
May 27 2018, 10:11 AM
Hahnfeld closed D47119: [OMPT] Fix test parallel/not_enough_threads.c.
May 27 2018, 10:11 AM

May 25 2018

Hahnfeld committed rOMP333285: [libomptarget-nvptx] loop: Determine if runtime uninitialized.
[libomptarget-nvptx] loop: Determine if runtime uninitialized
May 25 2018, 9:01 AM
Hahnfeld committed rOMP333284: [CMake] Unify install path for libraries.
[CMake] Unify install path for libraries
May 25 2018, 9:01 AM
Hahnfeld committed rL333284: [CMake] Unify install path for libraries.
[CMake] Unify install path for libraries
May 25 2018, 9:00 AM
Hahnfeld committed rL333285: [libomptarget-nvptx] loop: Determine if runtime uninitialized.
[libomptarget-nvptx] loop: Determine if runtime uninitialized
May 25 2018, 9:00 AM
Hahnfeld closed D47131: [libomptarget-nvptx] loop: Determine if runtime uninitialized.
May 25 2018, 9:00 AM
Hahnfeld closed D47130: [CMake] Unify install path for libraries.
May 25 2018, 9:00 AM
Hahnfeld committed rC333283: [Sema] Add tests for weak functions.
[Sema] Add tests for weak functions
May 25 2018, 9:00 AM
Hahnfeld committed rL333283: [Sema] Add tests for weak functions.
[Sema] Add tests for weak functions
May 25 2018, 9:00 AM
Hahnfeld closed D47200: [Sema] Add tests for weak functions.
May 25 2018, 9:00 AM
Hahnfeld added a comment to D47224: [cmake] Guard another instance where symlinks are being created.

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.

May 25 2018, 8:57 AM
Hahnfeld accepted D47221: [cmake] Fix libomptarget/test/CMakeLists.txt.

You are absolutely right, thanks for spotting this!

May 25 2018, 8:56 AM

May 22 2018

Hahnfeld created D47201: [CUDA] Implement nv_weak attribute for functions.
May 22 2018, 8:54 AM
Hahnfeld created D47200: [Sema] Add tests for weak functions.
May 22 2018, 8:51 AM
Hahnfeld added a comment to D47131: [libomptarget-nvptx] loop: Determine if runtime uninitialized.

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 22 2018, 8:49 AM

May 21 2018

Hahnfeld created D47131: [libomptarget-nvptx] loop: Determine if runtime uninitialized.
May 21 2018, 2:42 AM
Hahnfeld created D47130: [CMake] Unify install path for libraries.
May 21 2018, 2:42 AM

May 20 2018

Hahnfeld added a comment to D44186: [OpenMP] New clang/libomptarget map interface: remove translation code.

Was the new map interface added to Clang and just missed it?

May 20 2018, 8:24 AM · Restricted Project
Hahnfeld removed a reviewer for D42427: Fix broken OpenMP runtime test cases for Windows: Hahnfeld.
May 20 2018, 8:20 AM
Hahnfeld added a dependent revision for D47119: [OMPT] Fix test parallel/not_enough_threads.c: D47106: [FileCheck] Make CHECK-DAG non-overlapping.
May 20 2018, 8:17 AM
Hahnfeld added a dependency for D47106: [FileCheck] Make CHECK-DAG non-overlapping: D47119: [OMPT] Fix test parallel/not_enough_threads.c.
May 20 2018, 8:17 AM
Hahnfeld created D47119: [OMPT] Fix test parallel/not_enough_threads.c.
May 20 2018, 8:16 AM

May 19 2018

Hahnfeld updated subscribers of D47070: [CUDA] Upgrade linked bitcode to enable inlining.

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 19 2018, 1:27 AM

May 18 2018

Hahnfeld added a comment to D47070: [CUDA] Upgrade linked bitcode to enable inlining.

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...

May 18 2018, 2:20 PM
Hahnfeld added a comment to D46842: [OpenMP][libomptarget] Make bitcode library building depend on clang and llvm-linker being available .

Your argument that an older version is better is actually wrong. Using an older version to build the BCLIB is always a BAD idea. The reason why you want to build the BCLIB is so that the runtime functions actually get inlined. If you use an older compiler the functions will not be inlined which defeats the purpose of having the BCLIB in the first place. I stumbled again upon this problem today after updating to the latest changes.

To be precise, I didn't say that "an older version is better". My statement was that it works and that older versions of the compiler generate bitcode files that are compatible with a larger number of (newer) compilers.

But you are right, inlining of old bitcode files broke last month with rC329829. Luckily, this can be fixed, see D47070.

I do not understand why you are opposing this, so far I haven't heard a single strong argument against this.

"strong" is certainly subjective and may imply different things for you and me. If I wanted to put my point to the extreme, I'd say that there is none of your arguments left because I sat down and fixed all the problems you have been describing so far.

Coming back to my opinion: I don't like using the just-built compiler because that's not how CMake usually works when you build a project.

You're correct, this is not how CMake normally works. However, CMake is also not normally being used to build a compiler. Compiler builds often self host to some degree or another, and the compiler provided to the build system is generally through of only as something necessary to bootstrap the build process. LLVM/Clang, being both a self-hosting compiler and also a library component, has a split personality in this regard. However, in this case, as I believe we do with compiler-rt components, etc., it makes sense to default to using the just-built clang to build the bitcode library (which is intended to be used by that just-built compiler).

May 18 2018, 10:40 AM
Hahnfeld added a comment to D47073: Document and Enforce new Host Compiler Policy.

I don't think this change actually compiles, did it work for you?

May 18 2018, 8:35 AM
Hahnfeld updated subscribers of D46842: [OpenMP][libomptarget] Make bitcode library building depend on clang and llvm-linker being available .

Your argument that an older version is better is actually wrong. Using an older version to build the BCLIB is always a BAD idea. The reason why you want to build the BCLIB is so that the runtime functions actually get inlined. If you use an older compiler the functions will not be inlined which defeats the purpose of having the BCLIB in the first place. I stumbled again upon this problem today after updating to the latest changes.

May 18 2018, 8:31 AM
Hahnfeld created D47070: [CUDA] Upgrade linked bitcode to enable inlining.
May 18 2018, 8:01 AM

May 16 2018

Hahnfeld committed rOMP332495: [libomptarget-nvptx-bc] Pass found CUDA installations.
[libomptarget-nvptx-bc] Pass found CUDA installations
May 16 2018, 10:25 AM
Hahnfeld committed rOMP332494: [libomptarget-nvptx] Test bitcode compiler flags and enable by default.
[libomptarget-nvptx] Test bitcode compiler flags and enable by default
May 16 2018, 10:24 AM
Hahnfeld committed rL332495: [libomptarget-nvptx-bc] Pass found CUDA installations.
[libomptarget-nvptx-bc] Pass found CUDA installations
May 16 2018, 10:24 AM
Hahnfeld closed D46930: [libomptarget-nvptx-bc] Pass found CUDA installations.
May 16 2018, 10:24 AM
Hahnfeld committed rL332494: [libomptarget-nvptx] Test bitcode compiler flags and enable by default.
[libomptarget-nvptx] Test bitcode compiler flags and enable by default
May 16 2018, 10:24 AM
Hahnfeld closed D46901: [libomptarget-nvptx] Test bitcode compiler flags and enable by default.
May 16 2018, 10:24 AM
Hahnfeld added a comment to D46901: [libomptarget-nvptx] Test bitcode compiler flags and enable by default.

@gtbercea I'd like to keep that discussion in D46842. Short answer: It's working for me.

May 16 2018, 6:32 AM
Hahnfeld added a dependent revision for D46901: [libomptarget-nvptx] Test bitcode compiler flags and enable by default: D46930: [libomptarget-nvptx-bc] Pass found CUDA installations.
May 16 2018, 1:41 AM
Hahnfeld added a dependency for D46930: [libomptarget-nvptx-bc] Pass found CUDA installations: D46901: [libomptarget-nvptx] Test bitcode compiler flags and enable by default.
May 16 2018, 1:41 AM
Hahnfeld created D46930: [libomptarget-nvptx-bc] Pass found CUDA installations.
May 16 2018, 1:40 AM
Hahnfeld added a comment to D46842: [OpenMP][libomptarget] Make bitcode library building depend on clang and llvm-linker being available .

Can we double check this LLVM IR backward compatible thing? My understanding is that it is not that good, at least for the major versions.

May 16 2018, 1:38 AM

May 15 2018

Hahnfeld added a comment to D44992: [OpenMP] enable bc file compilation using the latest clang.

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 15 2018, 1:23 PM · Restricted Project
Hahnfeld added inline comments to D46901: [libomptarget-nvptx] Test bitcode compiler flags and enable by default.
May 15 2018, 1:22 PM
Hahnfeld created D46901: [libomptarget-nvptx] Test bitcode compiler flags and enable by default.
May 15 2018, 1:19 PM
Hahnfeld added a comment to D46842: [OpenMP][libomptarget] Make bitcode library building depend on clang and llvm-linker being available .

The just-built compiler is a reasonable default in my opinion. I don't see a downside to it.

May 15 2018, 12:45 AM

May 14 2018

Hahnfeld requested changes to D46842: [OpenMP][libomptarget] Make bitcode library building depend on clang and llvm-linker being available .

Nope, I repeatedly expressed concerns about doing this and it was repeatedly discussed, see D14254 around November 21st:

May 14 2018, 1:25 PM
Hahnfeld added a comment to D44992: [OpenMP] enable bc file compilation using the latest clang.

Has this been implemented elsewhere already? Last I tried this flag was still needed here in order to build the bitcode library compilation.

May 14 2018, 1:19 PM · Restricted Project

May 10 2018

Hahnfeld added a comment to D46540: [X86] ptwrite intrinsic.

Could you maybe add some short summaries to your patches? It's hard for non-Intel employees to guess what all these instructions do...

Well, I was thinking I could copy-paste this from https://software.intel.com/en-us/articles/intel-sdm :
"This instruction reads data in the source operand and sends it to the Intel Processor Trace hardware to be encoded
in a PTW packet if TriggerEn, ContextEn, FilterEn, and PTWEn are all set to 1. For more details on these values, see
Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3C, Section 35.2.2, “Software Trace
Instrumentation with PTWRITE”."

Do you think this would really help anyone? It appears to be just meaningless without larger context.
Those who ever need this, need to read a lot of these manuals anyways, I think noone in practice is going to be enlightened by such a short description.

That of course makes a lot more sense with simpler instructions, e.g. movdir64b - I can just describe that as something like "atomically moving 64 bytes".

May 10 2018, 9:01 AM