On 9/1/20 10:27 PM, John Fastabend wrote:
Yonghong Song wrote:
On 9/1/20 1:07 PM, Andrii Nakryiko wrote:
On Mon, Aug 24, 2020 at 11:47 PM Yonghong Song <yhs@xxxxxx> wrote:
bpf selftest test_progs/test_sk_assign failed with llvm 11 and llvm 12.
Compared to llvm 10, llvm 11 and 12 generates xor instruction which
Does this mean that some perfectly working BPF programs will now fail
to verify on older kernels, if compiled with llvm 11 or llvm 12? If
Right.
yes, is there something that one can do to prevent Clang from using
xor in such situations?
The xor is generated by the combination of llvm simplifyCFG and
instrCombine phase.
Another option would be to move it out of the isAsCheapAsAMove on the
John, do you mean the following change?
diff --git a/llvm/lib/Target/BPF/BPFInstrInfo.td
b/llvm/lib/Target/BPF/BPFInstrInfo.td
index 4298e2eaec04..7448a2499d40 100644
--- a/llvm/lib/Target/BPF/BPFInstrInfo.td
+++ b/llvm/lib/Target/BPF/BPFInstrInfo.td
@@ -293,9 +293,9 @@ let isAsCheapAsAMove = 1 in {
defm AND : ALU<BPF_AND, "&=", and>;
defm SLL : ALU<BPF_LSH, "<<=", shl>;
defm SRL : ALU<BPF_RSH, ">>=", srl>;
- defm XOR : ALU<BPF_XOR, "^=", xor>;
defm SRA : ALU<BPF_ARSH, "s>>=", sra>;
}
+ defm XOR : ALU<BPF_XOR, "^=", xor>;
defm MUL : ALU<BPF_MUL, "*=", mul>;
defm DIV : ALU<BPF_DIV, "/=", udiv>;
}
Tried the above change with latest trunk. xor still generated :-(
I did not trace down to exact llvm optimization location for this
particular optimization instance.
llvm side. But, probably better to force the workaround until kernels
get support. Even with it being more expensive it wouldn't mean we never
get it so likely not a great idea. Just thought it might be worth
mentioning. If you have your own llvm and don't have these kernels yet
it looks like a win.
The following is a hack to prevent compiler from generating xor's.
