[llvm-bugs] [Bug 37143] New: 16-bit loads produce incorrect code on AVR

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=37143

            Bug ID: 37143
           Summary: 16-bit loads produce incorrect code on AVR
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: AVR
          Assignee: unassignedbugs at nondot.org
          Reporter: keshav.kini at gmail.com
                CC: llvm-bugs at lists.llvm.org

Here is a .ll file:

  target triple = "avr-atmel-none"

  define void @foo(i16* %x) {
  entry:
    %0 = load i16, i16* %x
    %neg = xor i16 %0, -1
    store i16 %neg, i16* %x
    ret void
  }

llc from trunk today, with no command line options, compiles it to the
following assembly code (after removing comments and directives):

  foo:
    mov r30, r24
    mov r31, r25
    ld  r24, Z+
    ld  r25, Z
    com r24
    com r25
    st  Z, r24
    std Z+1, r25
    ret

I believe this is incorrect.  When loading %x from Z+1:Z into r25:r24,
Z is incremented, and it is not decremented again before storing the
complemented r25:r24 back into memory at Z+1:Z.  Therefore the program
writes to a pair of memory locations which are off by one from where
it should be writing.

Here's an altered assembly listing which corrects the issue:

  foo:
    mov  r30, r24
    mov  r31, r25
    ld   r24, Z
    ldd  r25, Z+1
    com  r24
    com  r25
    st   Z, r24
    std  Z+1, r25
    ret

By the way, are LDD and STD part of the core set of instructions which
all AVR devices must support?  (I assumed that since I didn't pass
"-mcpu" to llc, its instruction selection would be limited to that
core instruction set.)  The AVR ISA manual says "Not all variants of
this instruction is available in all devices. Refer to the device
specific instruction set summary." in the sections for the LD X, LD(D)
Y, LD(D) Z, ST X, ST(D) Y, and ST(D) Z instructions; but I wasn't able
to find out whether any of the variants *are* guaranteed to be
available in all devices.

Of course, even when LDD and STD are supported on a given device, it
may be advantageous not to use them since on some devices they take
more cycles to execute than other load/store variants, if I'm not
mistaken.

About the title of this bug -- I don't really know anything about the
internals of LLVM, but I notice that in
:/lib/Target/AVR/AVRInstrInfo.td , the definitions of STPtrPiRr,
STWPtrPiRr, STPtrPdRr, and STWPtrPdRr contain references to
"post_store" and "pre_store", while the corresponding definitions
LDRdPtrPi, LDWRdPtrPi, LDRdPtrPd, and LDWRdPtrPd don't seem to have
any similar references, so I've somewhat arbitrarily blamed the load
for causing the problem.  Maybe the problem is somewhere else
entirely, though.

Thanks,
    Keshav

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180416/6f0ab94b/attachment.html>