Carl Peto

I was about to raise a dupe... Found the same issue myself.

This LLVM IR is failing to compile and crashing LLC. ```` ; ModuleID = 'main_clean.ll' source_filename = "main.ll" target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-apple-macosx10.9" @start2 = external local_unnamed_addr...

This minimum llvm IR causes the crash: ```` define i32 @main(i32, i8** nocapture readnone) local_unnamed_addr { entry: %2 = tail call i8* @globalVal() %._value = bitcast i8* %2 to i16*...

That exactly what the compiler used to do before. This commit changed the behaviour: https://github.com/avr-rust/llvm/commit/87c4dc90ec85cd7d107adfe66e3707346b3ad796 The bug being fixed is that ld r24, X+ ld r25, X Is valid but...

Ran bugpoint to get a minimum test case: ```` define i32 @main(i32, i8** nocapture readnone) local_unnamed_addr { entry: %2 = load i16, i16* undef, align 2 tail call void @expect(i16...

OK have a hack patch you guys can use to get going for emergency purposes: https://github.com/avr-rust/llvm/pull/11 The patch is meant to limit the selection of the LDWRdPtr pseudo instruction to...

I’m sure you’re right generally. My guess is that because these are special registers, there are certain times where they have to be used and stack spilling isn’t an option,...

> Well, I think that the best option is to divide the LDWRdPtr into two versions. One will use displacements only and work with Y and Z only. The second...

p.s. On the subject of register pressure, I think there's also a sort of "underlying bug" that there should be no circumstances where you're _forced_ to use one of the...

I've come up with a patch that fixes it but I was surprised such a serious issue exists in the AVR back end. I just ran the unit tests and...