[llvm-dev] Is clang+llvm deterministisc?

Mehdi AMINI via llvm-dev llvm-dev at lists.llvm.org
Mon Jul 24 12:05:32 PDT 2017


2017-07-15 20:22 GMT-07:00 章明 via llvm-dev <llvm-dev at lists.llvm.org>:

> Hi, there,
>
>
> I am working on a project on software control flow checking, which
> instruments a program to check if the control flow at runtime matches the
> control flow graph computed at compile-time.
>
>
> My instrumentation process has to make use of control flow information,
> including as control flow graph and dominator/post-dominator trees, so it
> is better part of the compiler. On the other hand, I don't want any
> transformation pass to mess up the additional instrumentation code,
>
This isn't totally clear to me: the usual way to design the instrumentation
is to make it robust to IR transformations. What makes the instrumentation
special here that transforming the instrumented IR would break it?



> so my instrumentation process has to be run after other transformation
> passes are complete. Therefore, I'd like to implement my instrumentation
> process as the last pass before the machine intermediate representation
> (MIR) is translated to native assembly code.
>
>
> My instrumentation process also needs to take basic block execution
> frequencies into consideration. So I have to compile the same program
> twice. First, the program is compiled, adding code to collect execution
> frequencies. Then, when the execution frequencies have been collected, the
> same program is compiled again to add control flow checking instructions,
> which takes execution frequencies into consideration.
>

This is exactly what PGO is doing if I understand correctly your
description.


> Obviously, the program profiled to collect execution frequencies and the
> program instrumented with control flow checking instructions have to be
> consistent. At least, they have to have the same basic blocks and identical
> control flow graphs. So my question is this: If I compile the same program
> twice using Clang, with the same command line, is it guaranteed that, at
> the point right before the MIRs are converted to native assembly code, the
> MIRs are identical?
>

I believe any non-determinism here is considered a bug in clang/LLVM, and
should be fixed.

-- 
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170724/528530d4/attachment.html>


More information about the llvm-dev mailing list