Address review comments. Thanks @rjmccall !

In rG655ba9c8a1d22075443711cc749f0b032e07adee#1099379, @alexfh wrote:

Another issue without any custom expand / truncate implementations: https://github.com/llvm/llvm-project/issues/56204

I'll take care next time. Thanks @MaskRay !

Address review comments, thanks @craig.topper and @mingmingl!

Rebase

Reland again by rG655ba9c8a1d2, thanks!

Rebase.

Reland by rG04a3d5f3a119

Thanks Frederik! The optimized IR is really help. I can reproduce it with llc now. I'll investigate it.

If it failed in JIT compiler, it's possible a problem in JIT runtime too, see https://github.com/llvm/llvm-project/issues/55992

I think in general, we would like to prefer 512-bit vector on server. But notice the changes on arguments passing, which is ABI breaking. We need some downstream work before ready for the change. Please hold for a while, thanks!

@frgossen , can you please put the reproduce command together? I tried llc < crash.ll, but it passed on my side.

Fixed by rGe1c5afa

In rG6e02e27536b9de25a651cfc9c2966ce471169355#1095996, @bkramer wrote:

In rG6e02e27536b9de25a651cfc9c2966ce471169355#1095986, @pengfei wrote:

In rG6e02e27536b9de25a651cfc9c2966ce471169355#1095982, @bkramer wrote:

In rG6e02e27536b9de25a651cfc9c2966ce471169355#1095978, @pengfei wrote:

@bkramer Any reason on reverting this?

There's a test case in the message of the revert. The problem is a llvm.sqrt on <4xf16> not getting promoted anymore, crashing the compiler.

Thanks. I saw the test. I'll investigate it. What's the command to compile it?

You can translate it to LLVM IR and then run llc on it
mlir-translate -mlir-to-llvmir | llc
LLVM ERROR: Cannot select: t102: f16 = fsqrt t17

In rG6e02e27536b9de25a651cfc9c2966ce471169355#1095982, @bkramer wrote:

In rG6e02e27536b9de25a651cfc9c2966ce471169355#1095978, @pengfei wrote:

@bkramer Any reason on reverting this?

There's a test case in the message of the revert. The problem is a llvm.sqrt on <4xf16> not getting promoted anymore, crashing the compiler.

@tjoerg I have identified one issue in MLIR's runtime. See https://github.com/llvm/llvm-project/issues/55992
Not sure if it is the same root cause. Can you take a look?
By the way, what's the command to reproduce it? I don't have any experience on MLIR.

@bkramer Any reason on reverting this?

LGTM. The summary need to update too.

In D111029#3581880, @RKSimon wrote:

@pengfei Do you have any update on this please?

Change the title N in "1/N" to the actual number?

In D107082#3576355, @mehdi_amini wrote:

This broke the bot here: https://lab.llvm.org/buildbot/#/builders/61/builds/27616

The cmake invocation includes some GPU specific options that you can omit (-DMLIR_ENABLE_CUDA_RUNNER=1 , -DCMAKE_CUDA_COMPILER=/usr/local/cuda/bin/nvcc, -DMLIR_ENABLE_VULKAN_RUNNER=1, -DMLIR_RUN_CUDA_TENSOR_CORE_TESTS=ON), which should leave out:

cmake ../llvm.src/llvm -DLLVM_BUILD_EXAMPLES=ON '-DLLVM_TARGETS_TO_BUILD=host;NVPTX' -DLLVM_ENABLE_PROJECTS=mlir  -DMLIR_INCLUDE_INTEGRATION_TESTS=ON  -DBUILD_SHARED_LIBS=ON -DLLVM_CCACHE_BUILD=ON -DMLIR_ENABLE_BINDINGS_PYTHON=ON  -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON '-DLLVM_LIT_ARGS=-v -vv' -GNinja

You can probably leave out other options too:

cmake ../llvm.src/llvm '-DLLVM_TARGETS_TO_BUILD=host' -DLLVM_ENABLE_PROJECTS=mlir  -DMLIR_INCLUDE_INTEGRATION_TESTS=ON -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON '-DLLVM_LIT_ARGS=-v -vv' -GNinja

We had a discussion about the builtins between GCC and Clang on D109658 last year. We tried to make sure the same builtins have the same arguments and behavior. There's still a big gap among others.
We don't pursue all the builtins are identical for two reasons:

Address Yuanke's comments.

Address Yuanke's comments. Thanks!

Address review comments. Thanks @MaskRay for the thorough review!

1. Revert the change to clang/docs/ClangCommandLineReference.rst
2. Update missing options
3. Rebase on D126511

This is also fine to me. I'll rebase on it if @nickdesaulniers accept this.

Address @MaskRay 's comments. Thanks for the review!

Address Shengchen's review comments.

Address @nickdesaulniers 's comments. Thanks for the review!

Address @nickdesaulniers 's comments. Thanks for the thorough review and suggestions!

In D126137#3530777, @kristof.beyls wrote:

See https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html, documentation for "mharden-sls": For AArch64, the options available on the command line are "retbr", "blr", "none" and "all".
I don't think the options necessarily have to be the same for x86.
But assuming I understand this patch correctly, it seems to me that with this patch -mharden-sls=all would mean fundamentally slightly different things for x86 vs arm and aarch64, which could be confusing to users.
IIUC this patch correctly, this patch implements the equivalent of aarch64/arm's -mharden-sls=retbr (i.e. add a straight-line-speculation mitigation for returns and indirect jumps, but not for indirect function calls).
Therefore, I wonder if it wouldn't be better to name this -mharden-sls=retbr for more consistency across architectures?
Or is the indirect function call case not relevant for x86 (sorry - I'm not up to speed on the details on the x86 side)?

Or does MBB.back().getDesc().isIndirectBranch() also return True for indirect calls, in which case my whole remark here can probably be ignored?

Replaced isIndirectBranch with isUnconditionalBranch + isReturn.

Address Craig's comment.

Fix a few minor issues. I think it's mature for review now.

Adjust libcall lowering according to GCC code generation.

Replace gnu_f2h_ieee/gnu_h2f_ieee with truncsfhf2/extendhfsf2 to match with GCC.

Use 32-bit spill slot for half type. Others still on going.

In D125789#3519433, @sheisc wrote:

In D125789#3519411, @pengfei wrote:

I think another way is to report the issue to GCC. From the perspective of the user, GCC should support both {%k1} {z} and {%k1}{z}. Then we don't need the clange on LLVM.

Yes. It is a good idea.
However, it appears that there is no such white space in the instructions as described in Intel's manuals.
So I don't know which one should be the correct format.
Anyway, not a big issue.
I found this problem when using the fuzzer (i.e. AFL) to build Firefox.

I think another way is to report the issue to GCC. From the perspective of the user, GCC should support both {%k1} {z} and {%k1}{z}. Then we don't need the clange on LLVM.

I guess a lot of lines of tests need to update

$ grep -rn " {z}" llvm/test/CodeGen/X86/ | wc -l
7797

LGTM. Thanks!

Rebased on the avx512fp16 implementation. Still WIP for optimizations and a fast RA issue.

LGTM.

LGTM.

LGTM, thanks!

In D125170#3498913, @RKSimon wrote:

If people prefer we can alternatively use \code{.unparsed} .. \endcode blocks - I'm unsure if these operation blocks are being used in a particular way downstream

LGTM, thanks!

These intrinsics are interesting. The descriptions on Intrinsic guide are for immediate variant, but all compilers' implementations are register variant. What's more, the codegen from Clang and GCC don't seem correct according to the description of vpsrlw zmm0, zmm0, xmm1. They should do the same broadcast as ICC. https://godbolt.org/z/dcrqdEs8q

In D125164#3498752, @RKSimon wrote:

Actually the ia32_tzcnt builtins should stay the way they are - other C/C++ intrinsics return unsigned so we'd still end up with adding explicit casts

What do you want to do about _mm512_maskz_srli_epi16 ? The Intel Intrinsic guide has the same mismatch.

One question: is it better to change the define of builtins than explicit casts?