[AVR] Mulhi3/mulqi3 regression test

[tomtor]

See #152028

[Patryk27]

cc @benshi001 as well

[tomtor]

@Patryk27 The regression is back?!

Edit: just that Rust nightly-2025-08-10-x86_64-unknown-linux-gnu fails again....

[Patryk27]

Huh, weird - from what I've gathered, the issue is that Rust's LLVM fork generates a somewhat longer assembly output, right?

[tomtor]

Huh, weird - from what I've gathered, the issue is that Rust's LLVM fork generates a somewhat longer assembly output, right?

Yes, starting 2025-08-07. But this morning nightly was ok again.

62735d2 introduced the fix after introducing the bug 3 days earlier (see commit messsge), so it is not a real Rust issue, it is in the llvm used by Rust nightly, which apparently is very up-to-date..

mulqi3 was no longer generated for an 8bit modulo operation, but instead mulhi3 (which is the longer assembly) because the 8bit value was wrongly extended to 16bit. I have no clue why Rust nightly is wrong again.

This PR just rebased on current llvm and it runs fine.

[tgross35]

62735d2 introduced the fix after introducing the bug 3 days earlier (see commit messsge), so it is not a real Rust issue, it is in the llvm used by Rust nightly, which apparently is very up-to-date..

Rustc stays pretty up to date - usually the major version bumps get merged as soon as we know LLVM's release date will be before Rust's stable release date for that cycle (after a few months of testing), and minor bumps happen immediately. But that commit and the one that fixed it are still too new to have made it to our fork https://github.com/rust-lang/llvm-project/commits/rustc/21.1-2025-08-01/.

Maybe it regressed with the llvm bump but got fixed with a more codegen change on Rust's side?

(probably not worth all that much investigation if it's fixed now)

[tomtor]

@tgross35

Thanks for the feedback, but the nightly build fails since 2025-08-07 till today:

searched nightlies: from nightly-2025-08-01 to nightly-2025-08-08
regressed nightly: nightly-2025-08-07
searched commit range: rust-lang/rust@ec7c026...7d82b83
regressed commit: rust-lang/rust@dc0bae1

[tgross35]

Ah sorry! I thought you were saying it was fixed in rustc (not just llvm)

[tomtor]

Ah sorry! I thought you were saying it was fixed in rustc (not just llvm)

@tgross35 Its confusing, but I just tested again nightlies 2025-08-xx:

06 ok
07 fail
08 ok
09 ok
10 ok

So only 2025-08-07 failed, and it is indeed fixed now. Sorry for my inconsistent messaging, but yesterday it looked as if it failed again. Probably mixed up viewing release and debug builds.

Still strange that only 07 fails, but as you said, not worth the trouble of investigating if it is ok now. Thanks!

[tomtor]

It is a regression in llvm:

#153156

This PR needs a different test (and a fix:-) )

(And it IS present in current Rust, but my test script tested binary sizes instead of the actual generated code :/ )