<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-07-15 20:22 GMT-07:00 章明 via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p>
        Hi, there,
</p>
<p>
        <br>
</p>
<p>
        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.
</p>
<p>
        <br>
</p>
<p>
        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, </p></blockquote><div>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?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p>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.
</p>
<p>
        <br>
</p>
<p>
        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. </p></blockquote><div><br></div><div>This is exactly what PGO is doing if I understand correctly your description.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p>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?
</p></blockquote><div><br></div><div>I believe any non-determinism here is considered a bug in clang/LLVM, and should be fixed.</div><div><br></div><div>-- </div><div>Mehdi</div></div></div></div>