dmgreen added a comment. In D72934#1829387 <https://reviews.llvm.org/D72934#1829387>, @simon_tatham wrote:
> In D72934#1829331 <https://reviews.llvm.org/D72934#1829331>, @dmgreen wrote: > > > What is the reason that this can't be lowered in tablegen, in the same way > > as the VMOVimm's are? > > > In NEON, immediate VBIC is represented as a single MC instruction, which > takes its immediate operand already encoded into the NEON format (8 data > bits, op and cmode). That's the same format that `ARMISD::VBICIMM` has > encoded the operand in after lowering. So you only need one tablegen pattern, > which passes the immediate through unchanged between the input and output > SDNode types. > > In MVE, immediate VBIC is represented as four separate MC instructions, for > an 8-bit immediate shifted left by 0, 8, 16 or 24 bits. Each one takes the > immediate operand in the 'natural' form, i.e. the numerical value that would > be combined into the vector lane and shown in assembly. For example, > `MVE_VBICIZ16v4i32` takes an operand such as `0xab0000` which NEON VBIC would > represent as `0xab | (control bits << 8)`. So the C++ isel code I've written > has to undo the NEON encoding and turn it back into the 'natural' immediate > value plus a choice of which MVE opcode to use. > > I suppose an alternative would be to rework the MC representation of MVE > VBIC/VORR so that they look more like the NEON versions. I don't exactly know > why MVE was done differently in the first place (the commit here has my name > on it, but it was a team effort). One possibility is that the > pseudo-instruction reversed forms `vand` and `vorn` might be hard to > represent that way, but I don't know. I believe that the downstream VMOVimm's were rewritten like this when the other BUILDVECTOR handling was added by DavidS. If it is possible to structure this way for BIC's too, it sounds like it might be a little cleaner. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D72934/new/ https://reviews.llvm.org/D72934 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
