[llvm-dev] Adding a NOP bitcode instruction

[Bruce Hoult via llvm-dev]

I'm not really sure what a NOP even means in SSA. Sure, you can make the
assembler and disassembler and interpreter do the right thing, but in any
optimisation pass the right thing will be to delete them.

If you don't want them to be deleted then, as they have no inputs and no
outputs, optimisation could well decide to move other instructions up past
a NOP, move it out of loops, etc, until it ends up after the return
instruction.

If you don't want instructions to be moved past it ... it will have to be
like a memory barrier instruction, except even stricter.

What do you want it to do?

By the way, Apple's B3 optimiser in WebKit (which they wrote to replace
LLVM there) does have a NOP instruction -- and an IDENTITY instruction,
which also is meaningless in SSA. When an optimisation wants to delete an
instruction it turns it into a NOP instead. When an optimisation in LLVM
would do a "replace all uses with", B3 inserts an IDENTITY instruction. A
later pass deletes all NOPs and propagates inputs of IDENTITYs to their
(recursive) users.


On Wed, Jul 6, 2016 at 10:49 AM, Arno Puder via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
> Hi,
>
> I'm trying to follow the instructions on how to add a new bitcode
> instruction:
> http://llvm.org/docs/ExtendingLLVM.html
>
> This is my first foray into the guts of LLVM and I'm not sure I'm doing
> things the right way. I came up with a patch that adds a NOP (no
> operation) that will work with llvm-as, llvm-dis, and lli. It would be
> nice if one of the experts could take a look and give some quick feedback:
>
> https://github.com/apuder/llvm/commit/c58b0c65ac367c8a392a94063afe39b66daa01d4
>
> TIA,
> Arno
> _______________________________________________
> 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/20160706/72159272/attachment.html>