search for: bpf_alu64

...i, > > Currently, LLVM eBPF backend always generate code in 64-bit mode, this may > cause troubles when JITing to 32-bit targets. > > For example, it is quite common for XDP eBPF program to access some packet > fields through base + offset that the default eBPF will generate BPF_ALU64 for > the address formation, later when JITing to 32-bit hardware, BPF_ALU64 needs > to be expanded into 32 bit ALU sequences even though the address space is > 32-bit that the high bits is not significant. > > While a complete 32-bit mode implemention may need an new ABI (somethi...

...> > this may > > > cause troubles when JITing to 32-bit targets. > > > > > >    For example, it is quite common for XDP eBPF program to access > > > some packet > > > fields through base + offset that the default eBPF will generate > > > BPF_ALU64 for > > > the address formation, later when JITing to 32-bit hardware, > > > BPF_ALU64 needs > > > to be expanded into 32 bit ALU sequences even though the address > > > space is > > > 32-bit that the high bits is not significant. > > > > &g...

...gets. >> >>>>> >> >>>>> For example, it is quite common for XDP eBPF program to access >> >>>>> some packet >> >>>>> fields through base + offset that the default eBPF will generate >> >>>>> BPF_ALU64 for >> >>>>> the address formation, later when JITing to 32-bit hardware, >> >>>>> BPF_ALU64 needs >> >>>>> to be expanded into 32 bit ALU sequences even though the address >> >>>>> space is >> >>>&gt...

In BPF, an ADD instruction is defined as a 2 register instruction: 0x0f. add dst, src. dst += src In BPFInstrInfo.td this kind of ALU instruction is defined with: def _rr : ALU_RR<BPF_ALU64, Opc, (outs GPR:$dst), (ins GPR:$src2, GPR:$src), "$dst "#OpcodeStr#" $src", [(set GPR:$dst, (OpNode i64:$src2, i64:$src))]>; How does tablegen+codegen ensure that dst and src2 are the same register?...