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

[paolo via llvm-dev]

Hi all,

I'm currently working on the implementation for LLVM of the RISCV Bit
Manipulation ISA extension described by Clifford Wolf in the following
presentation:

https://content.riscv.org/wp-content/uploads/2019/06/17.10-b_wolf.pdf

and the following document:

https://github.com/riscv/riscv-bitmanip/blob/master/bitmanip-0.90.pdf

The aim is to provide the intrinsic functions to the user in order to
implement code that is more optimal for bit manipulations on RISCV
targets, but also to provide automatic optimization by lowering simple
code patterns into optimized bit manipulation assembly,

    %neg = xor i32 %1, -1                    ----->      andn t0, t0, t1
    %and = and i32 %0, %neg

just in case the user wants such optimization but is not aware of all
the bits that can be optimized.


I'm dealing with the fact that it is pretty hard to select some patterns
of DAG nodes in order to replace them with an optimal machine equivalent
machine instruction.

Take for intsance the count leading zeros operation:


    uint32_t clz (uint32_t x)

    {

        for (int count = 0; count < 32; count++ ) {

            if ((x << count) < 0)

                return count;

        }

        return 32;

    }


It needs a loop to be performed and that makes it difficult to be
lowered because it goes through several basic blocks, and different
optimizations can easily compromise the pattern recognition.


What I'm wondering is, is there already any place in LLVM where complex
patterns like this are already lowered into single instructions? (e.g.:
clz, that is used quite often). Maybe at a higher level?


Another point of view that I've been suggested and that I'd like to
discuss is: does it make sense to implement such lowering for operations
that normally a user wouldn't implement from scratch when an intrinsic
function is already available for that?


Many thanks.

Paolo Savini

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 2456 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190814/858b3f8f/attachment.key>