jdoerfert's comments

This is not true.

3. is supported by AMD on new hardware, e.g., Frontier. See https://docs.olcf.ornl.gov/systems/frontier_user_guide.html#...

Yes, though with caveats. The driver and parts of the extended API we used to lower CUDA calls are in upstream LLVM. The wrapper headers are not. We will continue the process of getting it all to work in upstream/vanilla LLVM soon though. Help is always appreciated.

FWIW, we have some alternative ideas on how to get out of the vendor trap, as well as some existing prototypes to deal with things like CUBLAS and Thrust. Feel free to reach out, or just keep an eye out.

Shameless plug: https://www.osti.gov/servlets/purl/1892137

TLDR; If you provide even more functions through the overloaded headers, incl. "hidden ones", e.g., `__cudaPushCallConfiguration`, you can use LLVM/Clang as a CUDA compiler and target AMD GPUs, the host, and soon GPUs of two other manufacturers.

Generally, yes. Though, as always, these things are hard to summarize in one sentence and depend on the standard version (pre/post C++11). This post might shed some light on the options we are considering for Clang right now: https://reviews.llvm.org/D94367#2489090

Since https://reviews.llvm.org/D86841, ~ Aug 2020, Clang is able to reason about the forward progress guarantees of the input. For the LLVM-IR handling see https://reviews.llvm.org/D86233. While we are still adding more fine-grained support of different language standards and corner cases, e.g., constant loop condition in C vs. C++, you should be able to tell LLVM a loop is allowed to loop forever w/o side-effect. In fact, that is the new default. That said, LLVM still removes calls to functions without side effect unconditionally. We are working on that, i.a., https://reviews.llvm.org/D94106.

FWIW, `noalias`, aka. `__restrict__`, generally works fine but the inliner translates it into `noalias` metadata which is, still, ambiguous and also not handled properly in some cases. Loop unrolling is one of them but that will be fixed with https://reviews.llvm.org/D92887, a general problem is the ambiguity itself.

There is a major effort to revamp the `noalias`/`restrict` handling going on for a while now. It takes quite long because it is hard and complex and we want to get it right.

In case you are interested, here is the new design https://reviews.llvm.org/differential/changeset/?ref=2170825 here the overall code changes currently considered https://reviews.llvm.org/D69542 and here you can find information on our monthly LLVM Alias Analysis call https://docs.google.com/document/d/1ybwEKDVtIbhIhK50qYtwKsL5...

Does this sound interesting: http://llvm.org/docs/ProgrammersManual.html#llvm-adt-indexed... http://llvm.org/doxygen/IndexedMap_8h_source.html

Clang will not "reduce compilation effort" and I do not believe GCC does that. There are heuristics that look at things like function size but I don't think that is what they mean. Generally speaking, translation units are independent if you do not run link-time-optimizations (LTO) and optimizations follow a (basically) predetermined order which might be influence by the input but not by the amount of work done.

The godbolt compiler explorer, which is awesome btw, had to tackle all sorts of problems like this. I think there is a talk on YouTube that goes into some detail.

It would be news to me that the PolyhedralInfo interface is actually used anywhere. As the file comment says, this was "work in progress" a few years ago and it shares the same drawbacks as Polly (unfortunately).

Polyhedral development in LLVM stagnated a while ago, maybe we find the people and time to actually land the PolyhedralValueInfo (see for example this talk: https://www.youtube.com/watch?v=xSA0XLYJ-G0).