Do you have further optimizations that take advantage of 32-bit
subregisters and zero extension?
Should it be added in more generic way instead of pattern match?This is the last of the operations that can be implemented with just 64-bit
operands.A full and proper implementation of 32-bit operations takes quite a bit more
effort. I started on that one evening last week before realizing quite how
much, and had to put it aside for now.
great. pls share whenever it's ready.
For most cases native 32-bit arithmetic should boost performance.
Currently there are too many <<32 >>32 ops generated.
More important is probably to get signed division working instead of emitting
an error. I expect it ought to be similar to how Select is expanded, with
multiple blocks:
interesting idea. we decided not to introduce signed div insn,
since classic bpf doesn't have it and there wasn't a single case
where sdiv couldn't be replaced with udiv in C code,
but such compiler support is certainly nice.
Probably makes sense to add warn_once, so the user
is suggested to tweak the code manually, since these
extra branches not going to help performance.
btw we've been talking about introducing signed/unsigned <, <= ops.
That should clean up llvm side a bit and performance will improve,
but verifier need to work harder, since it pattern matches >
for packet access.
Speaking of verifier... there is a todo item to add register liveness
to improve search pruning.