Potential bug in shl operator implementation

[carlos4242]

avrio.c.txt
avrio.ll.txt
blink.s.txt

I notice that this IL...

pinMask.exit:                                     ; preds = %entry, %if.then7.i
  %conv.i.sink = phi i16 [ %sub.i, %if.then7.i ], [ %conv.i, %entry ]
  %shl.i = shl i16 1, %conv.i.sink
  %conv3.i = trunc i16 %shl.i to i8
  %tobool = icmp eq i8 %conv3.i, 0
  br i1 %tobool, label %cleanup, label %if.end

There is what looks like an error with the shl operator implementation.

This seems to be the assembly language created...

00000162 <LBB2_3>:
 162:	21 e0       	ldi	r18, 0x01	; 1
 164:	30 e0       	ldi	r19, 0x00	; 0
 166:	e0 15       	cp	r30, r0
 168:	21 f0       	breq	.+8      	; 0x172 <LBB2_5>

0000016a <LBB2_4>:
 16a:	22 0f       	add	r18, r18
 16c:	33 1f       	adc	r19, r19
 16e:	e1 50       	subi	r30, 0x01	; 1
 170:	e1 f7       	brne	.-8      	; 0x16a <LBB2_4>

00000172 <LBB2_5>:

I think the issue is with cp r30, r0. I don't see anywhere in the full assembly that r0 is set, meaning that it could be any value. After a power on it should probably be 0 so this may work in most cases but it looks like a bug. Should it not instead be cpi r30, 00?

It's pretty weird that this IL resulted from compiling the attached c file as I've tried very hard to force unsigned char as the data type everywhere but that's a front end issue rather than an IL -> AVR ASM issue.

[shepmaster]

Hello! This is the AVR-Rust repository; could you please show the corresponding Rust code that generates the issue? Otherwise, you are probably better off opening an issue on the LLVM issue tracker

[gergoerdi]

I have a fix for this at avr-rust/llvm@910429c, looks like I forgot to file the bug.

[dylanmckay]

Fix upstreamed in r304284

[dylanmckay]

Fix has been cherry picked into avr-support branch in 301cc4e.