Stupid question: why assembler instead of builtins:
https://github.com/gcc-mirror/gcc/blob/master/gcc/testsuite/gcc.target/ia64/builtin-fma-1.c
I guess there is a tradeoff between control over the process and helping the register allocator.

For comparison:
https://github.com/llvm/llvm-project/blob/main/libc/src/string/memory_utils/memcpy_utils.h

For comparison:
https://github.com/llvm/llvm-project/blob/main/libc/src/string/memory_utils/memset_utils.h

I thought the Beyonce rule was: if you like a world without unicode characters, you need to put a CI test on it.

The C++ draft has some of these lints:
https://github.com/cplusplus/draft/blob/master/tools/check-source.sh#L25-L37

I see your point. It is more in terms of portability and a nicer API.

Are there plans for an LLVM LIBXAR?

Maybe a child diff with the new op?

There is now an official revert policy:
https://reviews.llvm.org/D99305

early returns?

No problem.

No. Inheriting from multiple Classes.

struct ARM64: TargetInfo, ARMCommon {
...
}

But if ARMCommon already implements parts of TargetInfo, then it is fine.

Nope is fine. But it keeps the section and section_64 instead of the offset in getEmbeddedAddend.

tweak

Does ARMCommon need to inherit from TargetInfo? Can ARM64 inherit from ARMCommon and TargetInfo? Multiple inheritance is a bit hacky.

tweak

even smaller diff

minimize diff

less hacky

In D99633#2664082, @int3 wrote:

Please feel free to ignore me, but it looks odd to needle 32bit support through the ARM64 and X86_64 structs. Inheritance? Common base class?

I guess you're referring to the set32BitProperties thing? I was hoping to keep things like target->wordSize a direct field access instead of a virtual method, and I couldn't find a way to do it with inheritance... but maybe virtual methods are the way to go after all.

But target->wordSize also goes through the vtable?
And you are loosing section_64 and have to use the less type-safe offset.

Is sprinkling templates all over ObjFile better than ObjFile32 and ObjFile64?

Please ignore me, but it looks odd to needle 32bit support through the ARM64 and X86_64 structs. Inheritance? Common base class?

The OMPIRBuilder is the modern version of late outlining:
https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
You may consider to go that way with SYCL as well.

Would it help readability and portability to change unsigned long to either uintptr_t, uint32_t, or uint64_t?

Would you mind adding the file size and the number of cores to the summary?

ELF uses the same chunk size. I am wondering, why the chunk size is independent of the file size and the number of cores? E.g. why bother with chunks if you have 1 core? Or if if you link a 1GB file with 10 cores, you probably have too many chunks?

I started a private module map in https://reviews.llvm.org/D94924. It reduces the surface of the std module. Splitting large headers into smaller "tail" headers should support this effort.

@cjdb seemed to be afraid that the two implementations would diverge. I was merely hinting at adding tests as counter-prove. If the solution is macro-foo then I am fine with that.

Then you might want to add tests to show that

You mixed Swift and Rust?

Clang introduced _ExtInt exactly for those people:
http://blog.llvm.org/2020/04/the-new-clang-extint-feature-provides.html

I like the idea of ASCII-Art. My mind works better with examples and "pictures" then with long hard to read text.

LLVM is not a big fan of std::map:
https://llvm.org/docs/ProgrammersManual.html#map

blank line

Could you split large basic blocks into smaller ones?

llvm went from unsigned to llvm::Align. Maybe introduce a richer type to represent the size of something. The conversion from bits to bytes could be target specific?

You could put a comment at the top of the format header:
This library is still in development and there are no stability guarantees.

See

__STDC_VERSION__

in https://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html.

Feel free to ignore me, but:
https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/BinaryFormat/MachO.h
seems to be inspired by the Apple headers. It is not a one-to-one copy.

Does codesign.go make any differences?

There is also no LLVM-exception with a dash.

In D96482#2556325, @kristof.beyls wrote:

In D96482#2556315, @tschuett wrote:

If you would extend the paragraph, you could say:
"For reference the SPDX identifier is ..."

Yes, it could be helpful to also explicitly call out the SPDX identifier. However, there is also value in keeping that introductory paragraph as short as possible.
On balance, I think it's slightly better to not call out the SPDX identifier in that introductory paragraph.
Maybe there's value in explicitly calling out the SPDX identifiers in one of the later paragraphs?

Agreed. In fact, I could neither find a WITH nor a SPDX in the whole file.

If you would extend the paragraph, you could say:
"For reference the SPDX identifier is ..."

Some cmake magic to look for OpenSSL? If you can't find it, give a warning and disable code-signing?

https://go-review.googlesource.com/c/scratch/+/271866/5/cherry/codesign.go

But "Support for architectures other than x86_64" sounds like it is secret, which other ISAs you want to support.

The man page uses:

clangd has also machinery for detecting grpc:
https://reviews.llvm.org/D77794

Maybe you could the same for the status page? It was changed from XXX to YYY? It is claiming success without giving numbers.

Do what ever you want, but a lot sounds a bit cheap. Or give some concrete examples?

I would rather see it as that I am forced to do that. It is the only way to eliminate cyclic dependencies.

I would rather expect that we have to split some headers into smaller/modular ones.

• rebased
• sorted headers

1. You don't have to do anything.
2. If you use -fcxx-modules, it reduces the size of the surface of the std module. The std_private module is hidden from users. There is a " // FIXME: These should be private." in the module.modulemap. These headers should not be visible to users of the std module. The private module is exactly trying to do that.

You can see it as proof of concept. If you don't like, feel free to reject.

finally managed to get __bits running

more pseudo-private modules

add newline

In D94489#2503685, @teemperor wrote:

In D94489#2503662, @tschuett wrote:

There is no syntax highlighting for Python in sphinx? The code in
https://lldb.llvm.org/python_api/lldb.SBDebugger.html#lldb.SBDebugger
is hard to read.

Even the line breaks between the source code and web page differ.

There is, but someone (probably me) needs to rewrite and update all the documentation in restructured text so that sphinx knows this is a code example (previously we had just plaintext). Currently working on all that.

There is no syntax highlighting for Python in sphinx? The code in
https://lldb.llvm.org/python_api/lldb.SBDebugger.html#lldb.SBDebugger
is hard to read.

There is -nostdinc++.

Does it have to stay in llvm-nm.cpp? A different file for MachO stuff?

clang-format supports include blocks:

BasedOnStyle: LLVM
IncludeBlocks: Regroup
IncludeCategories:
  - Regex:           '^<.*\.h>'
    Priority:        2
  - Regex:           '^<.*'
    Priority:        6
  - Regex:           '^"(llvm|llvm-c)/'
    Priority:        5
  - Regex:           '^"(clang|clang-c)/'
    Priority:        4
  - Regex:           '^"\.\./'
    Priority:        3
  - Regex:           '.*'
    Priority:        1

The main supporting point for me is that it is peripheral and helps external users of LLVM,, like e.g. Tensorflow. I believe it is a completely different usage scenario than gn or cmake.

I just wanted to help you!

see https://reviews.llvm.org/D93912

Yes, if it could be part of the machine model. It is specific to your core.

fixed unittest

But LLVM is C++14:
https://github.com/llvm/llvm-project/blob/main/llvm/docs/CodingStandards.rst#id13

libclang take II

fix libclang

addressed review comments