Yonghong Song wrote:
>
>
> 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.
Agh I assumed that would work. I might have some time to mess
around with it tomorrow. Now I'm just curious why that is being
generated.
Thanks for trying!
