Page MenuHomePhabricator

Hahnfeld (Jonas Hahnfeld)
User

Projects

User does not belong to any projects.

User Details

User Since
Apr 2 2015, 4:52 AM (324 w, 4 d)

Recent Activity

Wed, Jun 9

Hahnfeld accepted D103606: [OpenMP][Tools] Cleanup memory pool used in Archer.

LG

Wed, Jun 9, 3:08 AM · Restricted Project

Tue, Jun 8

Hahnfeld accepted D103607: [OpenMP][Tools] Fix Archer for MACOS.

LG

Tue, Jun 8, 11:21 PM · Restricted Project
Hahnfeld accepted D103608: [OpenMP][Tools] Fix Archer handling of task dependencies.

LGTM, thanks

Tue, Jun 8, 11:17 PM · Restricted Project
Hahnfeld added inline comments to D103606: [OpenMP][Tools] Cleanup memory pool used in Archer.
Tue, Jun 8, 11:15 PM · Restricted Project

Mon, Jun 7

Hahnfeld added a comment to D103608: [OpenMP][Tools] Fix Archer handling of task dependencies.

I think at least this patch needs a clang-format, maybe also applies to the other recent patches.

Mon, Jun 7, 1:05 AM · Restricted Project

Sun, Jun 6

Hahnfeld added inline comments to D103606: [OpenMP][Tools] Cleanup memory pool used in Archer.
Sun, Jun 6, 11:26 PM · Restricted Project
Hahnfeld added inline comments to D103607: [OpenMP][Tools] Fix Archer for MACOS.
Sun, Jun 6, 11:12 PM · Restricted Project
Hahnfeld added inline comments to D103607: [OpenMP][Tools] Fix Archer for MACOS.
Sun, Jun 6, 8:31 AM · Restricted Project

May 19 2021

Hahnfeld added a comment to D96033: [clang-repl] Land initial infrastructure for incremental parsing.

We've started seeing LLVM ERROR: out of memory on our 2-stage LTO Linux builders after this change landed. It looks like linking clang-repl always fails on our bot, but I've also seen OOM when linking ClangCodeGenTests and FrontendTests. Do you have any idea why this could be happening? We'd appreciate any help since our bots have been broken for several days now.

Ouch. Are the bot logs public? If not maybe a stacktrace could be useful. clang-repl combines a lot of libraries across llvm and clang that usually are compiled separately. For instance we put in memory most of the clang frontend, the backend and the JIT. Could it be we are hitting some real limit?

Yes, they are, see https://luci-milo.appspot.com/p/fuchsia/builders/prod/clang-linux-x64, but there isn't much information in there unfortunately. It's possible that we're hitting some limit, but these bots use 32-core instances with 128GB RAM which I'd hope is enough even for the LTO build.

I think the specs are fine for just building with LTO, but I am not sure if that's enough to for the worst case when running ninja -j320 with an LTO build (which is what your job is doing). Can you try limiting your link jobs to something like 16 or 32 (e.g., -DLLVM_PARALLEL_LINK_JOBS=32)

May 19 2021, 3:40 AM · Restricted Project

Apr 7 2021

Hahnfeld committed rG6415f424bc2a: [AArch64] Materialize FP constant in code for large code model (authored by Hahnfeld).
[AArch64] Materialize FP constant in code for large code model
Apr 7 2021, 12:02 PM
Hahnfeld closed D99607: [AArch64] Materialize FP constant in code for large code model.
Apr 7 2021, 12:02 PM · Restricted Project
Hahnfeld added a comment to D98902: [Clang][OpenMP][NVPTX] Fixed failure in openmp-offload-gpu.c if the system has CUDA.

Can we get this fixed somehow? It's annoying that there is a test failure in Clang without building the OpenMP runtime, just because I have CUDA installed on my machine...

Apr 7 2021, 12:00 PM · Restricted Project
Hahnfeld added reviewers for D99607: [AArch64] Materialize FP constant in code for large code model: aemerson, paquette.

friendly ping :)

Apr 7 2021, 12:27 AM · Restricted Project

Mar 30 2021

Hahnfeld removed a reviewer for D34701: [openmp-target-tests] OpenMP 4.5 Target data test cases: Hahnfeld.
Mar 30 2021, 10:14 AM
Hahnfeld removed a reviewer for D73657: [OPENMP] Load plugins from same directory as the libomptarget.so and quick fail mechanism for offloading plugins: Hahnfeld.

Superseded by D87413, I think.

Mar 30 2021, 10:12 AM · Restricted Project
Hahnfeld removed a reviewer for D94332: [OpenMP] Introduce a new parallel region entry point: Hahnfeld.
Mar 30 2021, 10:10 AM · Restricted Project
Hahnfeld removed a reviewer for D89974: [driver][CUDA] Use CMake's FindCUDA as default --cuda-path.: Hahnfeld.
Mar 30 2021, 10:10 AM · Restricted Project, Restricted Project
Hahnfeld removed a reviewer for D87413: [OpenMP] Load plugins from same directory as the libomptarget.so: Hahnfeld.
Mar 30 2021, 10:10 AM · Restricted Project
Hahnfeld removed a reviewer for D85934: Enable OpenMP offloading to VE and enable tests for offloading to VE: Hahnfeld.
Mar 30 2021, 10:09 AM · Restricted Project, Restricted Project, Restricted Project
Hahnfeld removed a reviewer for D71987: [OpenMP][NFC] Add a couple of TODOs to the runtime: Hahnfeld.
Mar 30 2021, 10:08 AM · Restricted Project
Hahnfeld removed a reviewer for D70412: [OpenMP][Tool] Runtime warning for missing TSan-option: Hahnfeld.

Long addressed by D72779, but I can't seem to be able to close this (?)

Mar 30 2021, 10:08 AM · Restricted Project
Hahnfeld removed a reviewer for D47224: [cmake] Guard another instance where symlinks are being created: Hahnfeld.
Mar 30 2021, 10:04 AM
Hahnfeld requested review of D99607: [AArch64] Materialize FP constant in code for large code model.
Mar 30 2021, 9:55 AM · Restricted Project

Feb 4 2021

Hahnfeld added inline comments to D95915: [clang][driver] Only warn once about invalid -stdlib value.
Feb 4 2021, 8:36 AM · Restricted Project

Feb 3 2021

Hahnfeld added a comment to D95915: [clang][driver] Only warn once about invalid -stdlib value.

That's what I was looking at right now as well, since using std::call_once() already means the methods can't be const anymore anyway. Might as well just cache the value.

Feb 3 2021, 11:49 PM · Restricted Project
Hahnfeld added a comment to D95915: [clang][driver] Only warn once about invalid -stdlib value.

My proposal would be to cache the return value of the three routines in ToolChain. This has the advantage that the values get parsed only once and there is at most one warning. I don't know how this plays with parallelization efforts, but I don't think we should worry about this right now, given the current code.

Feb 3 2021, 11:37 PM · Restricted Project

Jan 9 2021

Hahnfeld accepted D93169: [OpenMP] Added the support for cache line size 256 for A64FX.

LGTM, thanks for the changes!

Jan 9 2021, 8:55 AM · Restricted Project

Jan 7 2021

Hahnfeld added inline comments to D93169: [OpenMP] Added the support for cache line size 256 for A64FX.
Jan 7 2021, 11:30 PM · Restricted Project
Hahnfeld added a comment to D93169: [OpenMP] Added the support for cache line size 256 for A64FX.

Why is it necessary to write and compile a C program just to parse /proc/cpuinfo? Can this be done directly from CMake?

Unfortunately we can't. CMAKE_SYSTEM_PROCESSOR just reports aarch64.

Jan 7 2021, 1:20 PM · Restricted Project
Hahnfeld added a comment to D93169: [OpenMP] Added the support for cache line size 256 for A64FX.

Why is it necessary to write and compile a C program just to parse /proc/cpuinfo? Can this be done directly from CMake?

Jan 7 2021, 9:25 AM · Restricted Project

Dec 16 2020

Hahnfeld committed rG6e890ec7beb0: [CMake] Avoid __FakeVCSRevision.h with no git repository (authored by Hahnfeld).
[CMake] Avoid __FakeVCSRevision.h with no git repository
Dec 16 2020, 8:34 AM
Hahnfeld closed D92718: [CMake] Avoid __FakeVCSRevision.h with no git repository.
Dec 16 2020, 8:33 AM · Restricted Project

Dec 15 2020

Hahnfeld updated the diff for D92718: [CMake] Avoid __FakeVCSRevision.h with no git repository.

Add comment for find_first_existing_vc_file, thanks @scott.linder.

Dec 15 2020, 12:13 PM · Restricted Project

Dec 13 2020

Hahnfeld added reviewers for D92718: [CMake] Avoid __FakeVCSRevision.h with no git repository: vsapsai, scott.linder.

Ping

Dec 13 2020, 7:45 AM · Restricted Project

Dec 5 2020

Hahnfeld requested review of D92718: [CMake] Avoid __FakeVCSRevision.h with no git repository.
Dec 5 2020, 4:10 AM · Restricted Project

Nov 13 2020

Hahnfeld updated Hahnfeld.
Nov 13 2020, 6:48 AM

Oct 22 2020

Hahnfeld added a comment to D89974: [driver][CUDA] Use CMake's FindCUDA as default --cuda-path..
In D89974#2348176, @tra wrote:

CUDA path is sort of a global configuration parameter for all CUDA compilations. Perhaps we should consider allowing the user to specify a CUDA search path candidate via environment variable. This should allow transparently overriding preferred CUDA path without having to adjust all builds. I can't say I like it, but it seems to be the least bad way (that I can think of ATM) to address the dependency on something that only the end user would know for sure.

Oct 22 2020, 12:18 PM · Restricted Project, Restricted Project
Hahnfeld added a comment to D89974: [driver][CUDA] Use CMake's FindCUDA as default --cuda-path..

I thought, right now we would configure clang with a cuda path XYZ

Oct 22 2020, 11:52 AM · Restricted Project, Restricted Project
Hahnfeld added a comment to D89974: [driver][CUDA] Use CMake's FindCUDA as default --cuda-path..
In D89974#2347938, @tra wrote:

I think the default should still let clang search for CUDA or require the user to provide correct CUDA path. "Use CUDA path discovered by CMake at build time" should be a non-default configuration option if/when it's needed and appropriate.

I agree here. It's definitely surprising to make it the *first* path because module loading another CUDA version and putting it into PATH is not recognized anymore.

Oct 22 2020, 10:53 AM · Restricted Project, Restricted Project
Hahnfeld added a comment to D89974: [driver][CUDA] Use CMake's FindCUDA as default --cuda-path..
In D89974#2347938, @tra wrote:

One concern I have is that the path we configure during clang's build is not necessarily the right choice for the user of clang we build. It's likely that the clang in the end will be used on a completely different machine.
E.g. official clang builds can not ever provide the same CUDA path for *all* users who end up using them. Requiring the rest to use a special option to make clang work again looks like an overall usability regression to me.

Oct 22 2020, 10:50 AM · Restricted Project, Restricted Project
Hahnfeld updated subscribers of D89915: [compiler-rt] Don't include libc++ headers from the source tree in MSAN.

By the way, there's no commit list subscribed which sounds bad. Adding llvm-commits to give people a chance to be aware of this.

Oct 22 2020, 12:27 AM · Restricted Project
Hahnfeld added a comment to D89915: [compiler-rt] Don't include libc++ headers from the source tree in MSAN.

@Hahnfeld Can you advise on the proper way to fix this? From git blame, it seems like you might know.

Oct 22 2020, 12:23 AM · Restricted Project

Sep 17 2020

Hahnfeld resigned from D87841: [openmp][libomptarget] Include header from LLVM source tree.
Sep 17 2020, 10:45 AM · Restricted Project, Restricted Project

Sep 3 2020

Hahnfeld added a comment to D87084: [OpenMP][AMDGPU] Use DS_Max_Warp_Number instead of WARPSIZE.

Other places need to be updated too: data_sharing_init_stack_common for one.

Do we actually use this array? What happens if you make it a single element and update the function above?

Sep 3 2020, 10:29 AM · Restricted Project

Jul 8 2020

Hahnfeld removed a reviewer for D83062: [OpenMP] Implement TR8 `present` map type modifier in runtime (2/2): Hahnfeld.
Jul 8 2020, 11:50 PM · Restricted Project

Jul 7 2020

Hahnfeld added a comment to D83268: [OpenMP][NFC] Remove unused (always fixed) arguments.

Aside from the API stability concern this looks uncontentious. Removes dead arguments, generally makes things simpler. Thus LGTM.

@Hahnfeld @ABataev - are you sufficiently persuaded that preserving the current interface is not worth the development cost?

Jul 7 2020, 7:21 AM · Restricted Project, Restricted Project, Restricted Project
Hahnfeld added a comment to D83268: [OpenMP][NFC] Remove unused (always fixed) arguments.

This is definitely not NFC and breaks API compatibility (but apparently nobody cares anymore?).

Jul 7 2020, 12:10 AM · Restricted Project, Restricted Project, Restricted Project

Jul 6 2020

Hahnfeld accepted D82267: [OpenMP][Tests] Fix/Mark compatibilty for GCC.

LGTM

Jul 6 2020, 12:30 PM · Restricted Project

Jul 5 2020

Hahnfeld added a comment to D82267: [OpenMP][Tests] Fix/Mark compatibilty for GCC.

The summary also talks about tools/multiplex/tests/*, is that information obsolete?

Jul 5 2020, 11:43 AM · Restricted Project
Hahnfeld accepted D83077: [OpenMP][Tests] Flag compatibility of OpenMP runtime tests with GCC versions.

LGTM

Jul 5 2020, 11:43 AM · Restricted Project
Hahnfeld accepted D83171: [OpenMP][OMPT] Fix ifdefs for OMPT code.

LGTM

Jul 5 2020, 11:43 AM · Restricted Project

Jul 2 2020

Hahnfeld committed rG0e0483bf5c38: [OpenMP][CMake] Fix version detection of testing compiler (authored by Hahnfeld).
[OpenMP][CMake] Fix version detection of testing compiler
Jul 2 2020, 10:49 AM
Hahnfeld added a comment to D82963: [OpenMP] Temporarily disable failing runtime tests for OpenMP 5.0.

Thanks @Hahnfeld. I realized that LLVM_MAJOR_VERSION was neither getting set in OpenMPTesting.cmake nor was it
inheriting it from anywhere else. So, OPENMP_TEST_COMPILER_VERSION_MAJOR was also getting set as empty, which
was getting propagated to lit by config.test_compiler_features. That is why "clang-11" was not getting recognized
as a valid target by lit-unsupported (though clang-11.0.0 would have worked). This change should fix this issue.

Jul 2 2020, 10:47 AM · Restricted Project
Hahnfeld added inline comments to D82963: [OpenMP] Temporarily disable failing runtime tests for OpenMP 5.0.
Jul 2 2020, 6:57 AM · Restricted Project

Jun 29 2020

Hahnfeld added a comment to D82718: [OpenMP] Use primary context in CUDA plugin.

(In general, all patches must be sent to the respective -commits list. This also makes feedback more likely.)

Sorry, I was not aware of -commits list. What is it for exclusively? If there is policy or instruction , please point me.
I added OpenMP project tag. I you watch OpenMP project on differential. I expect you get notifications. Is it not the case?

Jun 29 2020, 10:48 AM · Restricted Project
Hahnfeld updated subscribers of D82718: [OpenMP] Use primary context in CUDA plugin.

(In general, all patches must be sent to the respective -commits list. This also makes feedback more likely.)

Jun 29 2020, 9:10 AM · Restricted Project

Jun 19 2020

Hahnfeld added a comment to D76012: [OpenMP][Tool] Header-only multiplexing of OMPT tools.

@protze.joachim @jdoerfert ompt-multiplex.h is installed by default in /usr/include/
others opemp headers are installed in /usr/include/openmp/

Jun 19 2020, 2:07 AM · Restricted Project
Hahnfeld added a comment to D82154: [OpenMP][Tool] Fix install directory of ompt-multiplex.h.

LIBOMP_HEADERS_INSTALL_PATH is the internal compiler where for example omp.h. I think the header tool is of relevance outside of Clang, so IMO it should go the general include/ directory.

Jun 19 2020, 2:07 AM · Restricted Project

May 18 2020

Hahnfeld resigned from D80040: [compiler-rt][CMake] Fix PowerPC runtime build.

I don't feel comfortable reviewing this change, maybe @phosek can take a look.

May 18 2020, 6:24 AM · Restricted Project

May 15 2020

Hahnfeld added a comment to D79944: [OpenMP] Fix for https://bugs.llvm.org/show_bug.cgi?id=45904..

Does -fopenmp-version work with the Intel Compiler? How will this work if the GCC eventually gets support for OpenMP 5.0?

May 15 2020, 12:08 AM · Restricted Project

Apr 21 2020

Hahnfeld accepted D78566: [OpenMP] Add scaffolding for negative runtime tests.

LGTM as well

Apr 21 2020, 1:33 PM · Restricted Project
Hahnfeld added a comment to D78566: [OpenMP] Add scaffolding for negative runtime tests.

I just noticed another issue: ompt tests are skipped if FileCheck is not available. This is configured in openmp/runtime/test/lit.cfg. However, other openmp test suites that use FileCheck don't bother. Why is ompt different?

Apr 21 2020, 12:26 PM · Restricted Project
Hahnfeld added a comment to D78566: [OpenMP] Add scaffolding for negative runtime tests.

This patch makes not visible in all of the openmp project's test
suites. In all but libomptarget/test, it should be possible for a
test author to insert not before a use of the lit substitution for
running a test program.

Apr 21 2020, 9:41 AM · Restricted Project

Apr 10 2020

Hahnfeld added inline comments to D76843: [Openmp] Libomptarget plugin for NEC SX-Aurora.
Apr 10 2020, 1:35 AM · Restricted Project, Restricted Project

Apr 9 2020

Hahnfeld added inline comments to D76843: [Openmp] Libomptarget plugin for NEC SX-Aurora.
Apr 9 2020, 7:34 AM · Restricted Project, Restricted Project

Mar 30 2020

Hahnfeld committed rGced99a1a6368: Fix comment for CLANG_SYSTEMZ_DEFAULT_ARCH (authored by Hahnfeld).
Fix comment for CLANG_SYSTEMZ_DEFAULT_ARCH
Mar 30 2020, 1:04 PM
Hahnfeld added a comment to rGc506adcdf2ca: Move CLANG_SYSTEMZ_DEFAULT_ARCH to config.h..

@thakis thanks for taking care so quickly!

Mar 30 2020, 1:04 PM
Hahnfeld added inline comments to D75914: systemz: allow configuring default CLANG_SYSTEMZ_ARCH.
Mar 30 2020, 5:55 AM · Restricted Project, Restricted Project

Mar 26 2020

Hahnfeld added a comment to D76780: [OpenMP] Added memory barrier to solve data race.

Why doesn't the KMP_MB after the store to th_next_waiting guarantee that the unblocked thread sees that store?

Answering my own question, the ARM architecture reference manual states that the DMB instruction ensures that all affected memory accesses by the PE executing the DMB that appear in program order before the DMB and those which originate from a different PE, ...which have been Observed-by the PE before the DMB is executed, are Observed-by each PE, ...before any affected memory accesses that appear in program order after the DMB are Observed-by that PE.

I think this means, in this case, that the store of FALSE to th_spin_here is observed in the correct order only by the releasing thread that issued the DMB. Other threads (e.g. the spinning thread) could still see the updates to th_spin_here and th_next_waiting out of order, unless they also issue DMB, which is the fix in this patch.

Mar 26 2020, 1:03 AM · Restricted Project

Mar 25 2020

Hahnfeld accepted D76780: [OpenMP] Added memory barrier to solve data race.

Yes, this looks related to memory consistency. As far as I understand the threads synchronize on th_spin_here, so this is guaranteed to be updated. Any other write before this in __kmp_release_queuing_lock is not guaranteed to be synchronized by a weak memory model. This includes th_next_waiting (which triggers the assertion), but also writes by the user application. That's particularly bad because this should be taken care of by the runtime!

Mar 25 2020, 11:21 AM · Restricted Project

Mar 14 2020

Hahnfeld added a comment to D75001: [OpenMP][cmake] ignore warning on unknown CUDA version .

I like this way better. I was hoping we could do it in our cmake only :)

Give others a day or so to comment before your commit but I'm fine with this.

Well, that doesn't really work if openmp-commits is only subscribed on commit. That said, the solution is a bit ugly but I don't have an alternative right now.

What is the problem with openmp-commits here? I got the emails, didn't you?

Mar 14 2020, 2:06 AM · Restricted Project

Mar 6 2020

Hahnfeld committed rGf0689d2e6209: archer: Remove superfluous dot from warning message (authored by Hahnfeld).
archer: Remove superfluous dot from warning message
Mar 6 2020, 6:37 AM

Feb 25 2020

Hahnfeld added a comment to D75001: [OpenMP][cmake] ignore warning on unknown CUDA version .

I like this way better. I was hoping we could do it in our cmake only :)

Give others a day or so to comment before your commit but I'm fine with this.

Feb 25 2020, 6:56 AM · Restricted Project

Feb 11 2020

Hahnfeld resigned from D74258: [OpenMP] Switch default C++ standard to C++ 14.
Feb 11 2020, 12:47 AM · Restricted Project

Feb 8 2020

Hahnfeld added a comment to D74258: [OpenMP] Switch default C++ standard to C++ 14.

Unless there are good reasons to switch, I'd object because it requires newer versions of compilers than many HPC systems have.

I disagree. The use case we would be supporting is:

  • building llvm libomptarget from source
  • using it with a binary llvm dist, or some other toolchain
  • won't download or build a newer toolchain
Feb 8 2020, 4:24 AM · Restricted Project
Hahnfeld requested changes to D74258: [OpenMP] Switch default C++ standard to C++ 14.

This should have a RFC on openmp-dev. As far as I understand the linked patch, the aim is to use std::make_unique which is just syntactic sugar IMO. Unless there are good reasons to switch, I'd object because it requires newer versions of compilers than many HPC systems have.

Feb 8 2020, 3:48 AM · Restricted Project

Feb 3 2020

Hahnfeld accepted D73850: [OpenMP][OMPT] fix reduction test for 32-bit x86.

LGTM from the code, I didn't test that the issue is indeed fixed on i386 though

Feb 3 2020, 10:11 AM · Restricted Project

Feb 2 2020

Hahnfeld added a comment to D73850: [OpenMP][OMPT] fix reduction test for 32-bit x86.

@protze.joachim for 64 bit, we still need at least 5 threads IIRC

Feb 2 2020, 10:53 AM · Restricted Project

Jan 29 2020

Hahnfeld requested changes to D73657: [OPENMP] Load plugins from same directory as the libomptarget.so and quick fail mechanism for offloading plugins.

As a general comment, I think this patch should be split into at least two separate ones:

  1. Load plugins from the same directory as libomptarget.so is found.
  2. Quick fail mechanism, although I'm not sure how much this saves? In most cases, we won't have the plugins for a foreign architecture (PPC on x86) anyway, that might only be a concern for accelerators.
Jan 29 2020, 11:59 PM · Restricted Project

Jan 23 2020

Hahnfeld added a comment to D73249: [openmp] Disable archer if LIBOMP_OMPT_SUPPORT is off.

I'm not sure LIBOMP_OMPT_SUPPORT is guaranteed to be there yet when defined in runtime/.

If by 'guaranteed' you mean in the current code, then I've tested this patch with it being both true and false.

Jan 23 2020, 12:48 AM · Restricted Project
Hahnfeld added a comment to D73249: [openmp] Disable archer if LIBOMP_OMPT_SUPPORT is off.

I'm not sure LIBOMP_OMPT_SUPPORT is guaranteed to be there yet when defined in runtime/. Maybe it would be better to move the option to the top-level openmp/CMakeList.txt and rename it to OPENMP_OMPT_SUPPORT (with compatibility support for LIBOMP_OMPT_SUPPORT)

Jan 23 2020, 12:13 AM · Restricted Project

Jan 16 2020

Hahnfeld accepted D72779: [OpenMP][Tool] Fix memory leak and double-allocation.

LG

Jan 16 2020, 11:29 AM · Restricted Project
Hahnfeld added inline comments to D72779: [OpenMP][Tool] Fix memory leak and double-allocation.
Jan 16 2020, 12:35 AM · Restricted Project

Jan 15 2020

Hahnfeld added inline comments to D72779: [OpenMP][Tool] Fix memory leak and double-allocation.
Jan 15 2020, 10:03 AM · Restricted Project

Jan 14 2020

Hahnfeld added a comment to D70412: [OpenMP][Tool] Runtime warning for missing TSan-option.

This revision was not accepted before being committed!

It was a misunderstanding on my side. Johannes told me that he is fine with the changes before I pushed. I didn't check that the accepted flag was not on the patch.
What procedure do you suggest?

Jan 14 2020, 11:58 PM · Restricted Project
Hahnfeld reopened D70412: [OpenMP][Tool] Runtime warning for missing TSan-option.

This revision was not accepted before being committed!

Jan 14 2020, 12:21 PM · Restricted Project

Jan 6 2020

Hahnfeld updated subscribers of D72287: [OpenMP] Fix incorrect property of __has_attribute() macro.

Can you please also submit a patch to libc++ where we copied this code from?

Jan 6 2020, 12:24 PM · Restricted Project

Dec 31 2019

Hahnfeld added a comment to D71988: [OpenMP][WIP] Make the kmp_depend_info type fit in 128 bits..

I would expect that some versioning is needed..

Versioning is fine with me. Versioning the runtime would be even preferable.

Dec 31 2019, 2:33 AM · Restricted Project

Dec 30 2019

Hahnfeld requested changes to D71988: [OpenMP][WIP] Make the kmp_depend_info type fit in 128 bits..

Yes, this must not be changed for compatibility reasons. If this really brings a benefit, we need new entry functions and update the compiler(s).

Dec 30 2019, 2:50 AM · Restricted Project

Dec 11 2019

Hahnfeld added a comment to D71340: [VE,#3] Runtime libraries.

To clarify: this patch is not intended to be committed as-is but gives an overview of the required changes. It's the a patch of a series for the VE backend and includes all the earlier patches.

Dec 11 2019, 5:13 AM · Restricted Project, Restricted Project, Restricted Project, Restricted Project, Restricted Project, Restricted Project

Dec 7 2019

Hahnfeld committed rG071dca24cea9: [OpenMP] Require trivially copyable type for mapping (authored by Hahnfeld).
[OpenMP] Require trivially copyable type for mapping
Dec 7 2019, 4:34 AM
Hahnfeld closed D71134: [OpenMP] Require trivially copyable type for mapping.
Dec 7 2019, 4:34 AM · Restricted Project

Dec 6 2019

Hahnfeld added inline comments to D71134: [OpenMP] Require trivially copyable type for mapping.
Dec 6 2019, 12:06 PM · Restricted Project
Hahnfeld created D71134: [OpenMP] Require trivially copyable type for mapping.
Dec 6 2019, 10:50 AM · Restricted Project

Dec 2 2019

Hahnfeld removed a reviewer for D53250: [ToolChain] Use default linker if the toolchain uses a custom one: Hahnfeld.
Dec 2 2019, 7:55 AM · Restricted Project

Nov 29 2019

Hahnfeld added a comment to D70804: [Frontend] Allow OpenMP offloading to aarch64.

Tests are required

The tests for this were added in D30644, but they are currently failing on AArch64 due to D32035. This patch allows those tests to pass again. What further testing should I add?

Nov 29 2019, 12:10 AM · Restricted Project

Nov 19 2019

Hahnfeld added a comment to D70414: [libomptarget] Build a minimal deviceRTL for amdgcn.

Random drive-by comments to parts of the patch, I won't review in full.

Nov 19 2019, 1:20 AM · Restricted Project

Nov 16 2019

Hahnfeld removed a reviewer for D68100: [OpenMP 5.0] declare mapper runtime implementation: Hahnfeld.
Nov 16 2019, 9:58 AM · Restricted Project
Hahnfeld removed a reviewer for D55725: [OpenMP] Add libs to clang-dedicated directories: Hahnfeld.
Nov 16 2019, 9:58 AM · Restricted Project
Hahnfeld removed a reviewer for D28634: [buildbot] Extend libomp builder to test bot standalone and in-tree builds with and without clang bootstrapping.: Hahnfeld.

Testing of openmp is currently very lacking, but I don't think this change will apply cleanly anymore...

Nov 16 2019, 9:58 AM