Native support for AVR instrinsics

[Patryk27]

At the moment compiler-builtins isn't useful for AVR, because that platform uses a custom calling convention for intrinsics - supporting AVR here would require:

1. Implementing this custom calling convention in LLVM.
2. Exposing it in rustc.
3. Finally, using it within compiler-builtins.

There are no ongoing plans to do so yet, but over rust-lang/rust#131651 it was pointed out it would be nice to have some kind of message of this issue left, so here we go 🙂

[tgross35]

Thanks for filing this. I don't think we are blocked on LLVM having support for the calling convention, instead we should be able to use naked functions to translate the cc like we do for aeabi intrinsics

compiler-builtins/src/arm.rs

Lines 21 to 35 in cb06005

	// NOTE This function and the ones below are implemented using assembly because they are using a
	// custom calling convention which can't be implemented using a normal Rust function.
	#[naked]
	#[cfg(not(target_env = "msvc"))]
	pub unsafe extern "C" fn __aeabi_uidivmod() {
	core::arch::naked_asm!(
	"push {{lr}}",
	"sub sp, sp, #4",
	"mov r2, sp",
	bl!("__udivmodsi4"),
	"ldr r1, [sp]",
	"add sp, sp, #4",
	"pop {{pc}}",
	);
	}

.

I'm not positive how this would interact with the clobbers, however.

[Patryk27]

Oh, sure, that seems like a good idea 🙂

[tgross35]

Separately you may be interested in getting AVR asm to stable. This isn't a blocker for this crate but it may be useful in user code rust-lang/rust#93335

[tgross35]

Also, do you know if there is a version of these symbols in assembly that don't come from libgcc? Some of these are probably easy enough that we could provide our own assembly implementations, but we need to be careful with licensing.

[Patryk27]

Also, do you know if there is a version of these symbols in assembly that don't come from libgcc?

I'm aware only of the libgcc implementation, unfortunately.

[tgross35]

After rust-lang/rust#131651 merges it should be possible to fix the AVRTiny asm convention, at which point I think we will be okay to start using AVR assembly in this repo. The #[naked] wrapper to convert the ABI and forward to our implementations is probably still the best option.

[tgross35]

@Patryk27 do you happen to know which intrinsics we are actually missing? Testing with the below:

#![no_std]

#[unsafe(no_mangle)]
pub fn call_umulhisi3(a: &u16, b: &u16, r: &mut u32) {
    *r = *a as u32 * *b as u32;
}

#[unsafe(no_mangle)]
pub fn call_mulhisi3(a: &i16, b: &i16, r: &mut i32) {
    *r = *a as i32 * *b as i32;
}

#[unsafe(no_mangle)]
pub fn call_udivmodqi4(a: &u8, b: &u8, r1: &mut u8, r2: &mut u8) {
    (*r1, *r2) = (*a / *b, *a % *b);
}

#[unsafe(no_mangle)]
pub fn call_divmodqi4(a: &i8, b: &i8, r1: &mut i8, r2: &mut i8) {
    (*r1, *r2) = (*a / *b, *a % *b);
}

#[unsafe(no_mangle)]
pub fn call_udivmodhi4(a: &u16, b: &u16, r1: &mut u16, r2: &mut u16) {
    (*r1, *r2) = (*a / *b, *a % *b);
}

#[unsafe(no_mangle)]
pub fn call_divmodhi4(a: &i16, b: &i16, r1: &mut i16, r2: &mut i16) {
    (*r1, *r2) = (*a / *b, *a % *b);
}

On the atmega328p target-cpu (unsure whether this makes a difference), the only intrinsics from the list at https://gcc.gnu.org/wiki/avr-gcc#Exceptions_to_the_Calling_Convention are the 8- and 16-bit integer division __u?divmod[hq]i4. For the multiplication, LLVM seems to widen the integers to u32 and call the default builtin __mulsi3 which I don't think would have the special ABI. Do you typically see more missing symbols (beyond small int division) when you try linking projects without the AVR libgcc?

[Patryk27]

Status: was a little bit busy previous week, I'll take a look at those intrinsics and your example in a couple of days 🙂

[Patryk27]

You're right - it seems that the only Funny Intrinsics™ used at the moment are __udivmodqi4, __divmodqi4, __udivmodhi4, and __divmodhi4.

I have tried to summon __umulhisi3 with:

#[inline(never)]
pub fn fun(a: &u16, b: &u16, x: &mut u16, y: &mut u16) {
    (*x, *y) = a.widening_mul(*b);
}

... but even this causes LLVM to go with 16b->32b extension followed by 32b x 32b multiplication (aka __mulsi3).

All of those observations match the intrinsics actually hardcoded into the codegen:

https://github.com/llvm/llvm-project/blob/c979ce7e362908a361cee721d2a6db4bcd65be1f/llvm/lib/Target/AVR/AVRISelLowering.cpp#L201

... which confirms that we'd only have to provide __u?divmod[hq]i4.

Curiously enough, some time ago I thought that ABI conflicts were the reason why f32 is broken on AVR:

#527

... but since they don't have special ABI, it must be a codegen bug, actually (this particular investigation will follow on Rahix/avr-hal#641).

[Patryk27]

Alright, there is another kind of ABI mismatch happening, though!

Context:

• Problem with floats on atmega32u4 - `undefined reference to '__extendsfdf2'` Rahix/avr-hal#641 (comment)
• Problem with floats on atmega32u4 - `undefined reference to '__extendsfdf2'` Rahix/avr-hal#641 (comment)

tl;dr intrinsics like those:

compiler-builtins/src/float/cmp.rs

Line 114 in 7bec089

pub extern "C" fn __unordsf2(a: f32, b: f32) -> i32 {

... should (most likely?) return c_int instead of i32, as one some platforms (AVR notably) those are actually (expected to be) 16-bit numbers.

Edit: actually, it's not even c_int - that's how LLVM defines it:

• https://github.com/llvm/llvm-project/blob/1e6ba3cd2fe96be00b6ed6ba28b3d9f9271d784d/compiler-rt/lib/builtins/fp_compare_impl.inc#L22
• https://github.com/llvm/llvm-project/blob/1e6ba3cd2fe96be00b6ed6ba28b3d9f9271d784d/compiler-rt/lib/builtins/comparedf2.c#L58

Should be easy to implement with a regular cfg-guarded type alias.

[Patryk27]

It seems there's an ABI difference in regards to 32-bit division and remainder as well.

Instead of compiler-builtins' fn divrem(T, T, &mut Option<T>) -> T or even GCC's fn divrem(T, T, bool) -> T, AVR expects fn divrem(T, T) -> (T, T) (even for i32/u32) - it's not written down in GCC's docs, but that's what the codegen says:

https://github.com/llvm/llvm-project/blob/1e6ba3cd2fe96be00b6ed6ba28b3d9f9271d784d/llvm/lib/Target/AVR/AVRISelLowering.cpp#L572

... and that's what also came out when I was running avr-tester's random-math test-suite on compiler-builtins without any #[avr_skip] (i.e. it printed trash for division and remainder, which prompted me to investigate those ops).

Now that I have a deeper understanding of how the pieces come together, I see a light out of the tunnel - I'm preparing a pull request that gets rid of all/most #[avr_skip]s, we'll see how it goes.

[Patryk27]

Ok, it seems that implementing __udivmodsi4 this way:

#[cfg(target_arch = "avr")]
intrinsics! {
    #[maybe_use_optimized_c_shim]
    pub extern "C" fn __udivmodsi4(n: u32, d: u32) -> u64 {
        let (div, rem) = u32_div_rem(n, d);

        ((rem as u64) << 32) | (div as u64)
    }
}

... yields a working intrinsic!

Unfortunately we can't go with the simpler -> (u32, u32), because that forces a stack allocation instead of passing stuff through registers, but the bit-shifting approach is good enough - LLVM seems to correctly understand it as mostly a regalloc-hinting thingie.