[llvm-dev] [RFC][RISCV] Selection of complex codegen patterns into RISCV bit manipulation instructions

[Roman Lebedev via llvm-dev]

On Thu, Aug 15, 2019 at 12:41 PM paolo <paolo.savini at embecosm.com> wrote:
>
> Hi Roman,
> > That depends.
> > If there's LLVM intrinsic for it, then any normal optimization pass could do it.
> > In cttz's case it's mainly done in LoopIdiom pass.
> Oh yes. Thank you!
>
> Unfortunately several of the instructions of the bit manipulation
> extension don't seem to have an intrinsic already in LLVM.
>
> That will require to add some passes to the middle end.
>
> > Again, i'd say this is too broad of a question.
> > If there is LLVM IR intrinsic, then you only need to lower it,
> > and optionally ensure that middle-end passes form it from appropriate IR.
> >
> > If there isn't one, then yes, you'd want to match all the beautiful wilderness
> > of the possible patterns that combine into that instruction.
> >
> > While it's really tempting to just add IR intrinsic for everything,
> > please do note that a new intrinsic is completely opaque to the rest of LLVM.
> > It does not magically get peep-hole folds, so those would need to be added,
> > especially if you intend to form said intrinsic within the middle-end from IR.
> >
> > This may change some day when these peep-hole folds are auto-inferred,
> > but that is not so nowadays. Really looking forward to that.
> >
> It would be definitely interesting.
>
> Anyway adding such complex instructions to the middle end seems material
> for another patch. Unless things change in the meantime.
>
> For now we can provide a lower level optimization of smaller bit
> manipulation patterns.
>
> But I'll definitely look into adding those passes as they would provide
> much more optimization.

I'm not sure what you mean by "more passes" in the reply.
If there is no matching instruction/intrinsic, then i'm not sure how a
pass would help.

*Please* do note my comment about adding new instructions/intrinsics.
While it's not and immovable obstacle, it by no means should be treated lightly.
If you want to add new LLVM IR instruction/intrinsic, with intention of actually
producing it from other instructions in middle-end (as opposed to just lowering
it from compiler front-end, or not producing it in middle-end),
you must also consider how said new IR instruction/intrinsic will affect
all other optimization passes, and *that* cost *is* high.

E.g. if you add 'andn', you then need to find every fold that would look for
and(not(y), x) or and(x, not(y)) and teach it about 'andn'.
Things will be more fun with more complex patterns :)

> Many thanks.
>
> Paolo
Roman