<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sun, Nov 4, 2018 at 8:14 AM Carter Cheng <<a href="mailto:cartercheng@gmail.com">cartercheng@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks for the help. I have a couple follow up questions-<div><br></div><div>Where can I find the code which calculates the properties of inline asm nodes and examples of passes that make use of this information?</div></div></blockquote><div><br>Not sure exactly, probably... - ah, easier than I expected. So I wrote a trivial bit of C code that used inline asm ( "int main() { asm(""); }") and compiled that to LLVM IR with clang (clang -emit-llvm -S code.c) & I see that Clang lowers inline assembly to an LLVM IR 'call' instruction with the 'asm' modifier: "<span class="inbox-inbox-s1">call</span><span class="inbox-inbox-s2"> void asm sideeffect </span><span class="inbox-inbox-s3">""</span><span class="inbox-inbox-s2">, </span><span class="inbox-inbox-s3">"~{dirflag},~{fpsr},~{flags}"</span><span class="inbox-inbox-s2">() #</span><span class="inbox-inbox-s3">1</span><span class="inbox-inbox-s2">, !srcloc !</span><span class="inbox-inbox-s3">2"<br></span><br>So I go and look up the API documentation for the LLVM IR call instruction & search for anything asm related and find this: <a href="http://llvm.org/doxygen/classllvm_1_1CallInst.html#a731dfe719a1112a16f7b231183cae70c">http://llvm.org/doxygen/classllvm_1_1CallInst.html#a731dfe719a1112a16f7b231183cae70c</a><br><br>So you could look around in the LLVM codebase for anything that calls that function. Chances are it isn't too many places - because for most optimizations the fact that it's a call (& maybe the CallInst lets you query for particular properties like whether it interacts with memory, etc) probably gives enough info.<br><br>- Dave<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Thanks again,</div><div><br></div><div>Carter.</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 5, 2018 at 12:04 AM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sun, Nov 4, 2018 at 1:56 AM Carter Cheng via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello,<div><br></div><div>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.</div><div><br></div><div>1. How do compiler passes cope with inline assembly? Can this sometimes violate the optimization assumptions of the pass? </div></div></blockquote><div><br>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.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>2. What are good ways to verify and validate passes?</div></div></blockquote><div><br>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)<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div> 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?<br></div></div></blockquote><div><br>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).<br><br>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).<br><br>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.<br><br>- Dave<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div><br></div><div>Thanks in advance for your help,</div><div><br></div><div>Carter.</div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div>