> -----Original Message-----
> From: Jose E. Marchesi <jose.marchesi@xxxxxxxxxx>
> Sent: Wednesday, July 26, 2023 2:17 AM
> To: bpf@xxxxxxxxxxxxxxx
> Cc: Yonghong Song <yonghong.song@xxxxxxxxx>; Eduard Zingerman
> <eddyz87@xxxxxxxxx>
> Subject: Re: Register constraint in NEG instructions
>
>
> I see this in the verifier (bpf-next):
>
> if (opcode == BPF_NEG) {
> if (BPF_SRC(insn->code) != BPF_K ||
> insn->src_reg != BPF_REG_0 ||
> insn->off != 0 || insn->imm != 0) {
> verbose(env, "BPF_NEG uses reserved fields\n");
> return -EINVAL;
> }
>
> And along this llvm assembler test:
>
> |
> v
> // CHECK: 84 01 00 00 00 00 00 00 w1 = -w1
> w1 = -w1
>
> Is enough evidence that NEG is supposed to use only dst and not src. I am
> sending a fix for standarization/instruction-set.rst.
>
> > Hello.
> >
> > The neg (and neg32) instructions are documented to use (and encode)
> > both src and dst register operands in standarization/instruction-set.rst:
> >
> > BPF_NEG 0x80 dst = -src
> >
> > However, in llvm's BPFAsmParser::PreMatchCheck, it is checked that
> > both source and destination registers refer to the same register. If
> > they are not, an error is raised.
> >
> > Is this to speed up JIT to different architectures, some like x86
> > featuring `NEG reg' and others like aarch64 featuring `NEG reg1,reg2'?
> >
> > Should I send a patch for instruction-set.rst documenting the
> > requirement?
> >
> > Thanks.
I am adding bpf@xxxxxxxx to this thread, for context.
Dave
