[llvm-bugs] [Bug 39438] New: Load combining is excessively fragile

[via llvm-bugs]

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

            Bug ID: 39438
           Summary: Load combining is excessively fragile
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: luto at mit.edu
                CC: llvm-bugs at lists.llvm.org

This input:

#include <stddef.h>
#include <stdint.h>

uint16_t good_read16le(const uint8_t *src)
{
    return (uint16_t)(src[0] |
      ((uint16_t)(src[1]) << 8));
}

size_t bad_read16le(const uint8_t *src)
{
    return (uint16_t)(src[0] |
      ((uint16_t)(src[1]) << 8));
}

size_t unfortunate_read16le(const uint8_t *src)
{
    return good_read16le(src);
}

Generates this output:

good_read16le(unsigned char const*): # @good_read16le(unsigned char const*)
  movzx eax, word ptr [rdi]
  ret
bad_read16le(unsigned char const*): # @bad_read16le(unsigned char const*)
  movzx ecx, byte ptr [rdi]
  movzx eax, byte ptr [rdi + 1]
  shl rax, 8
  or rax, rcx
  ret
unfortunate_read16le(unsigned char const*): # @unfortunate_read16le(unsigned
char const*)
  movzx ecx, byte ptr [rdi]
  movzx eax, byte ptr [rdi + 1]
  shl rax, 8
  or rax, rcx
  ret

I'm willing to accept that there's a right way to write this (good_read16le)
and a wrong way (bad_read16le), but unfortunate_read16le() demonstrates that
even the "right" way to write this is to fragile to work reliably in a
nontrivial program.

(This can easily matter in real life.  x86 is bad at addressing arrays by
anything other than a native word-sized index, but, if an index is computed
using a combined load and upcast to a native word, the optimization is lost.)

-- 
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/20181025/2dc23216/attachment.html>