[PATCH] D106809: [clang-offload-bundler] Make Bundle Entry ID backward compatible

RKSimon added inline comments. Comment at: clang/test/Driver/clang-offload-bundler.c:405 +// Tests to check compatibility between Bundle Entry ID formats i.e. between presence/absence of extra hyphen in case of missing environment field +// RUN: clang-offload-bundler -unbundle -

[PATCH] D109497: [X86][AVX] Update _mm256_loadu2_m128* intrinsics to use _mm256_set_m128* (PR51796)

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGea685e1028c6: [X86][AVX] Update _mm256_loadu2_m128* intrinsics to use _mm256_set_m128*… (authored by RKSimon). Repository: rG LLVM Github Monorepo

[PATCH] D109225: [clang-nvlink-wrapper] Add documentation in clang docs

RKSimon added inline comments. Comment at: clang/docs/ClangNvlinkWrapper.rst:17 +files. It reads each input archive file to extract the archived cubin files as +temporary files. These temporary (*.cubin) files are passed to ``nvlink``. + saiislam wrote: > RKSimon

[PATCH] D109592: [clang-offload-bundler] Fix compatibility testing for non-assert builds

RKSimon added a comment. Could you keep the test coverage by splitting off the debug tests into another file with a "REQUIRES: assert" lit tag? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D109592/new/ https://reviews.llvm.org/D109592 ___

[PATCH] D109592: [clang-offload-bundler] Fix compatibility testing for non-assert builds

RKSimon accepted this revision. RKSimon added a comment. This revision is now accepted and ready to land. LGTM with one minor Comment at: clang/test/Driver/clang-offload-bundler-asserts-on.c:6 + +// RUN: %clang -O0 -target %itanium_abi_triple %s -c -o %t.o +// RUN: echo 'Conten

[PATCH] D109658: [X86][FP16] Change the order of the operands in complex FMA intrinsics to allow swap between the mul operands.

RKSimon added a comment. > Regarding this case, we already have a different name with GCC, I think it > worthwhile to use a different order for the swapping optimization. > With a bit research on AVX512IFMA, I found: > > 1. The use of C, A, B order in GCC is not consistent on its AVX512IFMA > bu

<    2   3   4   5   6   7