On 05/01/2018 20:05, Alexei Starovoitov wrote:
On Fri, Jan 5, 2018 at 7:01 AM, Charlemagne Lasse
<charlemagnela...@gmail.com> wrote:
First thing is the odd way how 8 bit loads to an uint8_t are handled
(see bug1_sec):
I could reproduce both issues on other targets on latest LLVm trunk@321940,
for example AArch64 (need to remove asm("llvm.bpf.load.byte") from the
testcase.
For the first issue, it seems to be i8/i16 will be promoted to i32, so for
bug1_sec, the sequence is:
t6: i32 = truncate t5
t8: i32 = and t6, Constant:i32<255>
t9: i64 = any_extend t8
while for ok1, it is;
t6: i32 = truncate t5
t9: i64 = any_extend t6
For ok1 sequence, LLVM is doing (aext (trunx x)) -> x, while for bug1_sec
sequence, LLVM is not doing combination which is correct as it doesn't
understand the return value of llvm.bpf.load.byte is zero extended to i64
so combine the bug1_sec sequence will lost the effect of and instruction.
For unknown reasons, the line "6:" was changed from an JNE to an JEQ.
LLVM is doing geneirc canonicalizations inside
lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:
// If the lhs block is the next block, invert the condition so that we can
// fall through to the lhs instead of the rhs block.
--
Regards,
Jiong
_______________________________________________
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
