llvm dev - Nov 2021 - AArch64 immediate expansion questions

Hi all,

I've been playing with AArch64 logical immediate encoding lately, and had
a few questions.

1) I wrote a blog post about optimised functions for encoding and decoding
logical immediates:

https://dougallj.wordpress.com/2021/10/30/bit-twiddling/

Would that be a desirable contribution? (I've been assuming not, as it's
unjustified optimisation. But it's my very biased opinion that the shorter
methods are easier to read and reason about, so I figured I'd ask.)

2) I came up with a method for encoding immediates as the exclusive-or of
two 64-bit logical immediates when possible. I'd quite like to contribute
this. Despite being complex, it encodes many useful immediates that
currently take three or four instructions in two instructions. (Draft
revision at https://reviews.llvm.org/D113358 - I'm currently waiting for
approval to join llvm-commits). As a first time contributor I'd appreciate
any thoughts or advice, but I was also wondering if someone could point me
in the right direction with the liveness (deadness?) logic in this code:

https://github.com/llvm/llvm-project/blob/e20f69f612/llvm/lib/Target/AArch64/AArch64ExpandPseudoInsts.cpp#L145-L176

The ORR case has none of the getDeadRegState logic of the MOVZ case, but
both can be created on their own, or followed by a MOVK, so I'm not sure
why they'd be different. Is that a bug? (Why are we doing any of this if
the destination is an unused definition?)

3) I also came up with a method for encoding immediates as the bitwise-and
or bitwise-or of two 64-bit logical immediates, in all possible cases not
handled by exclusive-or. However, this has diminishing returns. Scanning
hundreds of megabytes of real AArch64 code, I could only find a handful of
immediates that would use bitwise-and, and none that would use bitwise-or.
So should we encode every immediate someone might use as efficiently as we
can, or stick to cases with current real-world benefits?

Cheers,
Dougall