@gchatelet

I wanted to ask whether you want to put an AMDGPU.cpp and AMD.cpp file in the flang/lib/Frontend directory.

Could you hide the amdgpu and nvptx somewhere here clang -print-resource-dir in two different directories? One for AMD, one for NVPTX.

Do you want to move the AMDGPU changes into AMDGPU.cpp next to AMD.cpp? From the conversation, there seems to be more target specific behaviours.

Is this the first of ten vendors types? Do I need a flag to enable the PowerPC vector type or does it also work on other architectures?

In D144274#4219406, @david-arm wrote:

In D144274#4219397, @tschuett wrote:

There is no space for an InstCombineWithLoopInfo to avoid all the phase ordering issues?

Hi @tschuett, sorry I don't really understand what you mean. Can you explain what you would like me to do?

There is no space for an InstCombineWithLoopInfo to avoid all the phase ordering issues?

Proper GOT/PLT handling is not yet implemented.

In D142885#4209221, @fhahn wrote:

Rename to tryToBuildVPlanWithVPRecipes as suggested, thanks!

Now that building may fail, you could even call it tryBuildVPlanWithVPRecipes .

There was objection against using /usr/modules on discourse. I assumed that libc++ owns /usr/include/c++ and hides everything under there.

You can either pass parameters to passes or use different pass pipelines for different optimisation levels (in MLIR territory).

In D146163#4202969, @rickmark wrote:

Began discussion in Discord to see interest for other collaborators on this type of binding: https://discord.com/channels/636084430946959380/700158649129238591/1086362007684513844

Flang will also support OpenACC for offload. It is very similar to OpenMP.

Frontend is in the file name.

What is the policy on trivial braces in the frontend?

My only comment is: views look more modern than const-ref. The efficiency is not affected at all.

It is odd to me that instcombine has two modes: with and without loopinfo. Wouldn't completely removing loopinfo make instcombine better testable, hermetic, and predictable?

Really stupid question^{TM}: if you would put the cppm files into the include directory and provide cmake files to integrate into out-of-tree projects.

> ninja install-cmake-exports install-mlir-cmake-exports

LLVM installs theses cmake files so that other cmake projects can include them in their project. User could integrate files into their cmake project and have a target to build the pcm files.

Any binary that uses this feature is not forward portable to hardware
with a larger vector size. That's true for SVE as well.

I did not understood this sentence. AFAIK, SVE uses the ptrue instruction to generate a mask to only activate the necessary lanes. If I do fixed length SVE with 128 bit and you give a machine 2048 bits, then it should still work. Probably I missed something.

You cannot ship pcm files. They are tied to the clang`s git hash that they were built with. The pcm format could differ between 2 git commits.

https://llvm.org/docs/CodingStandards.html#anonymous-namespaces

Could you achieve the same with structured bindings?

According to the tests in https://reviews.llvm.org/D112025 it also supports f64.

Kudos. You found a pattern. At the top right, you will find Edit Related Revisions ....

The web interface says at several places "Context not available.". Did you git diff -U999999 main?
https://llvm.org/docs/DeveloperPolicy.html#id10

You tend to upload without context. Do you need a pointer for some help?

For AArch64 the default alignment is 0? I would have expected 128.

In D142420#4101422, @mnadeem wrote:

In D142420#4089859, @tschuett wrote:

Would it help to compile a lto.f90 to lto.o and check with llvm-objdump that there is a special section?

The .o is just llvm bitcode

I would have expected something ala:

flang -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda example.f90

In D133289#4096588, @aaron.ballman wrote:

In D133289#4037180, @tschuett wrote:

It surprised me that there are no type inference messages? The type of this auto is double. I only found warnings of misuse of auto and codegen tests.

Can you give a code example of what you expected to see a diagnostic for but aren't getting one?

This is probably only for testing and not for Clang users:

auto Float = 3.0; // note that Float is a float

Would it help to compile a lto.f90 to lto.o and check with llvm-objdump that there is a special section?

IDK. Clang 16 is fully is a fully conformant C++20 except for some DRs. Or beginning with Clang 16, we start a long-term project to overhaul the diagnostics.

https://llvm.org/docs/ProgrammersManual.html#picking-the-right-data-structure-for-a-task

I am not the only one who has a different background. If the introduction says this is the introduction of the release notes, I am not super motivated to read on. I would prefer to see some highlights to motivate the readers to continue reading.

Have you thought about adding a fuzzer for Flang ala
https://github.com/llvm/llvm-project/blob/main/libc/fuzzing/string/strcpy_fuzz.cpp

Could you model this approach instead as a VPlan transformation, instead of hardcoding unscalable flags. Transform: add tail folding. Transform: add masked tail folding. Transform: add scalar tail. Then you can take the cost model to decide which is more desirable.

Bugzilla is offline?

Are you looking for a LGTM? Is this a test Diff? You can commit such changes directly.

Sure.

If there are equivalent instructions in LLVM IR, you could touch the IR translator?

Could you please put an X86.rst file into llvm/docs? There is a Sphinx template with instructions.

EXPANSIVE_CHECKS will reshuffle the llvm::sort input: https://lists.llvm.org/pipermail/llvm-dev/2018-April/122576.html

The summary only says what you are doing. I am missing something about why.

• Can "x86.AMX" be a named constant somewhere? I found a lot of copies.
• Release note?

I though Clang Basic is a leaf library and must not depend on anything.

No, you don't. You cannot mix lock-free and mutex atomics. E.g, if loads are lock-free and stores use a mutex. Then you have lost atomicity. Your mutex version could do stores one byte at a time.

Up right you will find Edit Related Revisions....

Dependent of the build flags, we decide which warnings to enable or not? Do we have other warnings for ThinLTO?

It surprised me that there are no type inference messages? The type of this auto is double. I only found warnings of misuse of auto and codegen tests.

https://github.com/openucx/ucx/blob/master/src/ucs/datastruct/pgtable.h super optimized page table for a similar use case.

Did you look at Yaml I/O?

In https://reviews.llvm.org/D140415 there was similar question: pass or part of lowering? Could you register callbacks or some other magic into the lowering part to make it extensible for debug info, stack arrays, and more?

I believe you are arguing for a JSON file. The complexity of flags that want to pass to clang-scan-deps is too high. You even get some benefit of caching if you create a JSON file with several targets.

Are asserts the right solution or do you need control flow to check whether optionals have a value?

Halide is apparently using lld as a library: https://reviews.llvm.org/D140726

Rust does not really care whether cc is clang or gcc. My point is that it is safer to invoke clang and let it manage the link step.

Instead of invoking lld and copying the flags, could you invoke clang instead? The flags may change over time. Rust calls cc for linking.

Could you have a look at:
https://llvm.org/docs/CodingStandards.html#anonymous-namespaces

There is as trySextValue in APInt: https://reviews.llvm.org/D139683. Maybe you need a tryMul.

In D140241#4008549, @PeteSteinfeld wrote:

In D140241#4007759, @tschuett wrote:

Will you use the LLVM remarks facilities for optimisation reports?

I'm not familiar with the LLVM remarks facilities.

LLVM ships the same type: PointerIntPair.

Will you use the LLVM remarks facilities for optimisation reports?

Would __tuple_helpers or __tuple_utils be less ugly resp. obvious solutions to the challenge?

In D140226#4003794, @jhuber6 wrote:

In D140226#4003788, @tschuett wrote:

There are already SYCL specific attributes: https://reviews.llvm.org/D60455

We could potentially merge these all into some generic attribute since they all do the same thing on a conceptual level. The unique thing about the existing amdgpu_kernel and corresponding nvptx_kernel is that they don't rely on the language options like SYCL or CUDA. Though, semantically those are definitely involved because the kernel itself is only meaningful to whatever runtime is going to load it (e.g. CUDA or HSA) but we can probably consider that separately to the compilation itself and just think of these as calling conventions.

There are already SYCL specific attributes: https://reviews.llvm.org/D60455