avr-device VS llvm-project

Also note that some libraries in the ecosystem might still use a feature called llvm_asm that was removed from rustc in 2021, so those crates might need a while to migrate to the newer asm syntax (this feature is used to provide an inline AVR assembly, e.g. to implement a cycle-accurate delay); so far I've got patches merged to https://github.com/Rahix/avr-hal & https://github.com/Rahix/avr-device :-)

Take a look at the avr-device crate, it also explains how to add a new controller and how to get to the svd files.

https://github.com/llvm/llvm-project/blob/main/clang/docs/Bo...

Incidentally, this automatic branch-if-zero from LLVM is being improved.

First of all, a recent LLVM patch apparently changes codegen to use CMOV instead of a branch:

https://github.com/llvm/llvm-project/pull/102885

Beyond that, Intel recently updated their manual to retroactively define the behavior of BSR/BSF on zero inputs: it leaves the destination register unmodified. This matches the AMD manual, and I suspect it matches the behavior of all existing x86-64 processors (but that will need to be tested, I guess).

If so, you don't need either a branch or CMOV. Just set the register to 32 and then run BSR. If the value is zero, then BSR leaves the register unmodified and you get 32.

Since this behavior is now guaranteed for future x86-64 processors, and assuming it is indeed compatible with all existing x86-64 processors, LLVM will no longer need the old path regardless of what it's compiling for.

Note that if you're targeting a newer x86-64 version, LLVM will just emit TZCNT, which just does what you'd expect and returns 32 if the input is zero (or 64 for a 64-bit TZCNT). But as the blog post demonstrates, many people still build for baseline x86_64.

(Intel does document one discrepancy between processors: "On some older processors, use of a 32-bit operand size may clear the upper 32 bits of a 64-bit destination while leaving the lower 32 bits unmodified.")

Bolt can do quite a lot of optimizations: https://github.com/llvm/llvm-project/tree/main/bolt

That's from the OP blog, the intention of macro mess is to generate uniquely named local lambda.

Cleaner version is like: https://github.com/llvm/llvm-project/issues/100869#issue-243...

Another possibility is to avoid it in the first place by not allowing C++ function pointers that are not marked noexcept to be passed to C functions. I filed bugs against both GCC and LLVM requesting warnings:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118263

https://github.com/llvm/llvm-project/issues/121427

If/when they are implemented, they will become errors with -Werror.

My code is compiled against Clang trunk built at 9919295c with -O3 for the optimization level.

this is an LLVM project... you want this to work on Metal, ask apple to add a Metal backend to LLVM

https://github.com/llvm/llvm-project/tree/main/llvm/lib/Targ...