[llvm-dev] generating multiple instructions for a single pattern

Bruce Hoult via llvm-dev llvm-dev at lists.llvm.org
Fri Mar 2 06:41:11 PST 2018


RISC-V does this kind of thing, and the (new) LLVM back end has been
written to (hopefully!) be an example of best practice, so it should be a
good one to copy. The first (AUIPC) instruction adds the top 20 bits of a
32 bit offset to the current PC and puts the result into a temporary
register. The branch instruction then adds a 12 bit offset to the temporary
register.

The compiler *always* generates code this way. It's the linker's job to
detect when the AUIPC isn't necessary and delete it and convert the branch
to 12 bit PC-relative instead of register relative. You can turn this off
(in gnu ld) if you want faster links and don't care about the occasional
extra instruction.

On Fri, Mar 2, 2018 at 2:48 PM, David Chisnall via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On 2 Mar 2018, at 11:45, Nagaraju Mekala <nagaraju.mekala87 at gmail.com>
> wrote:
> >
> > yes they are dependent if the branch immediate value is > 0xffff then
> > the imm instruction should generate other wise only "br" instruction
> > is enough.
>
> This sounds as if you have two br instructions, one that takes an
> immediate and one that takes a register and requires that another
> instruction materialise the address in a register.  This is common to most
> targets - you will find lots of examples in the code - but the high-level
> picture is to describe both variants in TableGen with appropriate
> constraints on the range of the immediate.  SelectionDAG will pick the
> immediate version of the constraints match, otherwise it will pick the
> register version.
>
> David
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180302/71ff1a94/attachment.html>


More information about the llvm-dev mailing list