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: unassignedclangb...@nondot.org
Reporter: l...@mit.edu
CC: llvm-bugs@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._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
