There is:
https://llvm.org/doxygen/classllvm_1_1WithColor.html
and
https://reviews.llvm.org/rG990d0c71090836fb117e72c262d6d19b76f346cc

I remember that there was talk about a FloatCombine pass with costs.

Could you split this into smaller patches?
Does this support C++20 modules or is it limited to clang header modules?
Is there overhead in the non dependency scanning mode?

You could use __cplusplus to determine the C++ version.

Thanks! I have the feeling that Release wins at execution speed and is the fastest to build?

Thanks for driving this.

Using llvm-objdump to read properties of Go binaries.

This is a large patch.

@compnerd

Then I have to repeat myself. If you google for LLVM and CMAKE_BUILD_TYPE, you will only find a list of the types. There is no documentation about the trade-offs or recommendations.

Rather than changing the default and annoying or confusing people, improve the documentation! Have cmake print a link to the awesome documentation.

LGTM and thanks.

Tranfsorm -> Transform in the summary.

opertaion -> operation in the summary.

Are there remarks for the VectorCombine pass?

In D123050#3454577, @spupyrev wrote:

In D123050#3454138, @tschuett wrote:

There was a *very* brief discussion about system models on llvm-dev. Did you consider using something similar in bolt resp. llvm?
https://lists.llvm.org/pipermail/llvm-dev/2018-October/127319.html

Interesting, thanks for the pointer. Is there a discussion somewhere, i can only see a single message with RFC.

There was a *very* brief discussion about system models on llvm-dev. Did you consider using something similar in bolt resp. llvm?
https://lists.llvm.org/pipermail/llvm-dev/2018-October/127319.html

In D123645#3452505, @sivachandra wrote:

Still LGTM with the suggested inline fix.

In D121296#3443122, @sepavloff wrote:

In D121296#3403848, @arsenm wrote:

Could also use FewerElementsVector handling

Some support for fewerElements was added, but the support of vector types in X86 Global ISel is weak, and I could not make tests for this case. Some patches for this support are in work, but it is a long trail.

Unfortunately not. set and map seem to be very malloc heavy. I could not find any great alternatives in the LLVM manual.

I do not want to bother you at all:
https://llvm.org/docs/ProgrammersManual.html#map

This would silently reduce protection, when incompatible modules are linked?

Is there another EH frame parser in-tree? LLVM or LLDB?

In my example, they even promised that the flag will removed.

Thanks. I let Aaron go over the details.

In D123167#3434372, @beanz wrote:

In D123167#3434364, @tschuett wrote:

Relying on the parser to find semantic misbehavior sounds strange ...

I don't disagree. An alternative point: HLSL has no _syntax_ for pointers.

Relying on the parser to find semantic misbehavior sounds strange ...

In D123167#3434349, @beanz wrote:

In D123167#3434346, @tschuett wrote:

Do you need a SemaHLSL.cpp file similar to SemaSYCL.cpp?

Yes absolutely. I haven't yet added any Sema-specific validations yet that are complex enough to break out, but we will 100% get there soon.

Do you need a SemaHLSL.cpp file similar to SemaSYCL.cpp?

My bad. I though of a last resort before the system crashes.

In D122922#3433979, @int3 wrote:

You cannot query the maximum parallelism ondemand and then create the array?

It's a little fragile -- things would break if someone created more than one ThreadPool instance & gave each instance the max hardware parallelism

But then MAX_THREADS has the same problem? For two thread pools I would need 2 * MAX_THREADS ?

You cannot query the maximum parallelism ondemand and then create the array?

You cannot access/find the global thread pool? Sorry, wrong diff.

LGTM

https://reviews.llvm.org/D54604 used a really ugly flag:
-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang

Is -fsanitize=memtag-heap Android specific or target independent? It passes Android flags to the linker?!?

In D123002#3425422, @lxsameer wrote:

I've thought about it, but I had two pros for keeping it here in my head: 1) since the mlir-mode and the mlir-lsp-server are distributed with LLVM, maybe it is better to keep it here (for example to match the compatibility) 2) it might worth merging this client with the mlir-mode

wdyt?

Do you want to eventually upstream the support for MLIR to https://github.com/emacs-lsp/lsp-mode/?

Do you want to say something about buildbots, C++ features, and that you are not committing until foo.

Would you mind putting a high level description of the intent at the top of the main header.

In D122082#3395250, @beanz wrote:

In D122082#3394836, @nikic wrote:

Yes, opaque pointer support is a hard requirement for any new code introduced in LLVM.

In D120894#3375098, @CarolineConcatto wrote:

Removed unnecessary for loop from isInstUsedByGEP

In D120867#3360859, @paquette wrote:

I'm not sure how often musttail/tailcc appears in the LLVM test suite, but this didn't introduce any asserts there, and all of the tests pass.

@aschwaighofer Can you think of any (open source) Swift programs we can test this on? :)

Stupid question: this works with Windows as well? And the BTW sounds odd. gcc also decided to use a dash as the separator.

I found this:
https://llvm.org/docs/CodingStandards.html#use-namespace-qualifiers-to-implement-previously-declared-functions

If you could ask for a cherry-pick into the 14.x. It would be great, if LLVM 14 would have consistent cmake version requirements.

There was a discussion that -emit-llvm is considered a mistake.

In rGd3b26dea16108c427b19b5480c9edc76edf8f5b4#1061426, @dblaikie wrote:

In rGd3b26dea16108c427b19b5480c9edc76edf8f5b4#1061425, @xbolva00 wrote:

Dwarf Error: found dwarf version '12', this reader only handles version 2, 3, 4 and 5 information.
Dwarf Error: Invalid or unhandled FORM value: 0x25.

For me, ld crashed on Ubuntu 18 LTS; GNU ld (GNU Binutils for Ubuntu) 2.30. EOL: April, 2023. Such breaking change (not compatible with gcc) could be acceptable after EOL, IMHO.

Does it stop the linker from linking? What flags are involved (-Wl,--gdb-index? that's the only one I can think of that /has/ to parse DWARF to link - the others are for error message quality, which hopefully lld still produces some usable error message, even if it doesn't mention file/line/source for the symbols)

Thankfully I read on Phoronix that dwarf 5 is now default in Clang, but I can imagine many developers would not know how to workaround that dwarf errors.

Could put up some sort of FAQ somewhere? (potentially ask/answer on stackoverflow or the like, but maybe there's some place we could put it in LLVM documentation - it is mentioned in the release notes, at least, I think)

(also, looking forward, maybe lld/libdebuginfo it's using needs some better parser support - I'm not sure where it's getting the "12" version number from, and it could string-ify the form number 0x25, which is a standard form in DWARFv5 which it says it supports - none of that addresses the usability of lld with Clang's DWARFv5 right now, but googling around there are repeated cases of these error messages showing up around DWARF default transitions, etc, and being pretty inscrutible, mentioning broken DWARF versions and opaque form numbers, etc)

Maybe additional check like if ubuntu < 20 then default = 4?

I don't think we have any specific Ubuntu detection, or Linux OS version checking in Clang to determine which flags to pass.

Why didn't or cannot InstCombine catch this?

Interesting. I didn't know about it.

You are mixing aarch64 and ARM64. I always associate ARM64 with Apple and aarch64 with the rest (Unix).

This file describes the ABI for exporting the AArch64 CPU ID/feature registers to userspace. The availability of this ABI is advertised via the HWCAP_CPUID in HWCAPs.

https://github.com/torvalds/linux/blob/master/Documentation/arm64/cpu-feature-registers.rst
Is similar to how Intel is doing feature detection.

https://reviews.llvm.org/D118862
https://reviews.llvm.org/D118875

Feel free to ignore:
https://rustc-dev-guide.rust-lang.org/query.html

@dmgreen

https://reviews.llvm.org/D113630

I though modern LLVM is to return llvm::Expected<std::string>?!?

Maybe add a macro LLVM_ATTRIBUTE_RETURNS_ALIAS for documentation.

I prefer: #!/usr/bin/env python3

https://sarcasm.github.io/notes/dev/compilation-database.html#clang

You could mark the other revisions as child revisions with Edit Related Revisions... at the top right.

Do you believe this is a permalink? Maybe cite a paper of the algorithm?

I believe the Basic library in Clang does not depend on other Clang libraries. It is a tail library. Do you envision a Basic, Utility, ... library that does not depend on Clang and provides basic utilities.

As an outsider, similar to VectorCombine maybe other FooCombine passes (special purpose) with costs. As an addition/extension to InstCombine.

LGTM

There is precedence for checking WaMArch.size() in the file. I would expected !WaMArch.empty().

In D114542#3155048, @SjoerdMeijer wrote:

In D114542#3153131, @tschuett wrote:

In D114542#3153129, @SjoerdMeijer wrote:

In D114542#3153102, @david-arm wrote:

I think the main difference between SVE and MVE is that for MVE we have to set up some state before entering the loop, and perhaps the actual instruction that generates the predicate uses that state? Whereas for SVE we don't have that problem.

Yep, and I would need to refresh my memory and read the reference manual, but I am almost certain that for MVE we would get wrong results if overflow occurs in the VCTP instructions.

Could you add Metadata to the intrinsic to state the assumptions?

Something along those lines would probably be possible, but defeats the purpose of the intrinsic, which is about communicating information from the middle-end to the back-end. If we need an intrinsic and also meta-data to achieve this, then we should probably revise the definition of the intrinsic. But it looks like we don't need to do that at the moment, and we are also good for SVE.

In D114542#3153129, @SjoerdMeijer wrote:

In D114542#3153102, @david-arm wrote:

I think the main difference between SVE and MVE is that for MVE we have to set up some state before entering the loop, and perhaps the actual instruction that generates the predicate uses that state? Whereas for SVE we don't have that problem.

Yep, and I would need to refresh my memory and read the reference manual, but I am almost certain that for MVE we would get wrong results if overflow occurs in the VCTP instructions.