[cfe-users] eBPF: Odd optimization results with clang-5.0

[Jiong Wang via cfe-users]

On 05/01/2018 20:05, Alexei Starovoitov wrote:

> On Fri, Jan 5, 2018 at 7:01 AM, Charlemagne Lasse
> <charlemagnelasse at 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 at 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