Ping. Hopefully this is ready to go.

Added debug metadata to the testcase. Updated summary to refer to metadata in general, not specifically TBAA (although TBAA was mentioned in one specific context).

Ping. Could someone weigh in on this?

In D101533#2726641, @dfukalov wrote:

The type is actually added in the patch so if we'll leave std::pair, it is not needed.

In D101533#2726569, @sdesmalen wrote:

For this patch it's probably best to just follow precedent as to what was used before, i.e. cases that used std::pair<unsigned, MVT> should be changed to std::pair<InstructionCost, MVT>

LGTM

I'd have to take a closer look at this. You're right that these patterns won't match in this form, but the fixes may need to be different. The standard treatment of boolean vectors as somewhat equivalent to n-bit integers or having immediate value doesn't work well with Hexagon, so we have nodes like HexagonPTRUE or HexagonQTRUE (and the corresponding falses).

Looks ok to me, but waiting for the prerequisite patch to be finalized.

Yup, just got it. Thanks!

__builtin_complex was added in clang 12. This code won't compile with any released version of clang.

Thanks!

I'm inclined to accept this as is. There is definitely a limitation here that cannot be easily worked around.

For targets that make use of HW modes, register sizes are specific to a subtarget.

Gentle ping.

LGTM, but please respond to outstanding comments before committing.

This is fixed in https://reviews.llvm.org/D95585.

This compiles ok on my machine.

Aside from potentially disabling this build, I actually have multilib installed:

ii  gcc-7-multilib                   7.5.0-3ubuntu1~18.04                amd64        GNU C compiler (multilib support)
ii  gcc-multilib                     4:7.4.0-1ubuntu2.3                  amd64        GNU C compiler (multilib files)

I don't have CUDA, why is this being compiled on my system to begin with?

I don't have CUDA on my system, and now the build is broken:

[ 38%] Building LLVM bitcode target_impl.cu-cuda_80-sm_80.bc
In file included from /w/src/llvm.org/openmp/libomptarget/deviceRTLs/nvptx/src/target_impl.cu:14:
In file included from /w/src/llvm.org/openmp/libomptarget/deviceRTLs/nvptx/src/target_impl.h:15:
In file included from /usr/include/assert.h:35:
/usr/include/features.h:424:12: fatal error: 'sys/cdefs.h' file not found
#  include <sys/cdefs.h>
           ^~~~~~~~~~~~~
1 error generated.

It's already guarded---it's only set to CXX when linking with the Support library.

The problem is with linking the Support library from LLVM, which has a lot of C++ code. If I'm reading the CMakeLists.txt correctly, there is still an option to build libomp.so as a "standalone" library (line 138), where the C linking should be sufficient.

Mehdi has fixed this.

Committed in https://reviews.llvm.org/rGa2e6506c47b1.

Committed in https://reviews.llvm.org/rGa2e6506c47b1.

Could you try this patch? https://reviews.llvm.org/D94607

Thanks for the report, looking into it.

This commit broke compilation of debuginfo-tests/llvm-prettyprinters/gdb/mlir-support.cpp. The compile command for this file doesn't get the path to the tblgen-generated includes, and it fails with

In file included from /w/src/llvm.org/debuginfo-tests/llvm-prettyprinters/gdb/mlir-support.cpp:2:
/w/src/llvm.org/llvm/../mlir/include/mlir/IR/BuiltinTypes.h:638:10: fatal error: 'mlir/IR/BuiltinTypes.h.inc' file not found
#include "mlir/IR/BuiltinTypes.h.inc"
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.