[llvm-dev] Some questions about writing compiler passes.

[David Blaikie via llvm-dev]

On Sun, Nov 4, 2018 at 1:56 AM Carter Cheng via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hello,
>
> I have a couple basic questions about implementing compiler passes for
> llvm and was looking for a bit of help since I was looking to write an
> instrumentation pass of some sort. I am sort of new.
>
> 1. How do compiler passes cope with inline assembly? Can this sometimes
> violate the optimization assumptions of the pass?
>

Inline asm nodes in the intermediate representation (LLVM IR) have various
properties that prevent such violation - so optimizations can query the
inline asm node in the IR & it'll say things like "I modify memory", etc -
so the optimizations won't reorder it in ways that'd break the memory ti
would observe.


> 2. What are good ways to verify and validate passes?
>

Check out the contents of LLVM's test directory - that's how we check LLVM
optimizations do what's intended (though it doesn't validate that that
intent is correct, or that it doesn't have weird corner cases, etc)


> Can one prove them correct with Coq? Or is it a matter of running and
> dumping the AST pre and post transform and using tests to verify their
> correctness?
>

The AST isn't used for optimization in Clang/LLVM - Clang generates LLVM IR
from Clang's AST (the AST itself is basically immutable - the
requirements/invariants are a bit too complicated to readily modify it
while preserving those invariants) - then LLVM's optimization pipeline
operates on that IR before lowering it again to the machine code (with a
few short stops along the way).

Test cases for optimizations are generally written by having some input IR,
running it through one specific optimization, then validating that the IR
coming out the other end has certain properties that are desired (has one
constant instead of an add of two constants if it's a constant fold, for
example).

Sometimes there are efforts to more totally prove something correct -
either by brute force (I think we brute forced some of the machine
instruction encoding at one point, to make sure the assembler/disassembler
could roundtrip everything) or algorithmic proofs.

- Dave


>
> Thanks in advance for your help,
>
> Carter.
> _______________________________________________
> 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/20181104/f082081f/attachment.html>