Re: [v2][PATCH RFC] Add BPF AsmParser support in LLVM

Jiong Wang

- Adjusted constant load tests.
- Interleaved the expected results with input insns.

* Changed the disassembly output "ll" to "LL" in BPFInstPrinter.cpp.
This is because I noticed MC parser only accept "LL" as long long
Sorry for the confusion caused by "ll". I tested your patch and found that
both r = 5 and r = 5LL generated ld_imm64 insn. This is not what compiler
will do. Further debugging I found that this is due to my change to remove
"ll" from asmstring in the insn definition (.td file). Since the assembler is
patten matching based on asmstring. "r = 5" matched to ld_imm64 as well.

I just fixed the issue and restored " ll" suffix for ld_imm64 asmstring.
You can then restore your previous change to add "ll" as a valid identifier
in the middle of asm statement.
Hmm, I actually feel there is no need to offer an separate syntax for 64bit imm
encoding, it might be better to offer a unified single syntax "r = signed_imm"
to the user and the encoder (BPFMCCodeEmitter::encodeInstruction) guarantee to
choose optimal encoding.

Encoder could choose BPF_ALU64 | BPF_MOV | BPF_K for both "r1 = -1" and
"r1 = -1ll" while only resorting to BPF_LD | BPF_DW | BPF_IMM when the imm really
doesn't fit into 32bit (!isInt<32>(imm_opnd)), for example, "r1 = 0x1ffffffffll".

Anyway, patch updated, changes are:

- added "ll" back.
- updated the test cases for BPF_MOV | BPF_K in ALU64 class and
BPF_IMM | BPF_DW in LD class.
- Dropped the change from "ll" to "LL". If we decided to move to "LL" which is
in consistent with LLVM generic parser then could clean this up as a
separate patch.

Please review, thanks.


Join to automatically receive all group messages.