<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 31, 2014 at 8:27 PM, Nick Lewycky <span dir="ltr"><<a href="mailto:nlewycky@google.com" target="_blank">nlewycky@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">On 31 March 2014 20:20, David Majnemer <span dir="ltr"><<a href="mailto:david.majnemer@gmail.com" target="_blank">david.majnemer@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
================<br>
Comment at: include/llvm/IR/Instructions.h:1291<br>
@@ -1281,1 +1290,3 @@<br>
+  }<br>
   void setTailCall(bool isTC = true) {<br>
+    setInstructionSubclassData((getSubclassDataFromInstruction() & ~3) |<br>
----------------<br>
Wouldn't it make more sense to have `setTailCall` take an `enum TailCallKind` instead of having both `setTailCall` and `setTailCallKind` ?</blockquote></div></div></div></div></div></blockquote><div><br></div><div>I was nervous about implicit integral conversions from the enum to bool allowing old code to silently compile.  I could see removing setTailCall and leaving the new setter.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The point of having setTailCall is that tail-callness is a mutable property throughout the IR. The point of musttail is that it must be a tail call, hence it isn't mutable.</div>


<div><br></div><div>I'm not sure whether there should be a setter at all and instead we should require that musttail must be set at creation time and is immutable, or whether we should permit upgrading normal-tail-call to musttail, but you can't downgrade one.</div>
</div></div></div></blockquote><div><br></div><div>FWIW, LLVM IR is already pretty mutable.  It's possible to slap alwaysinline on a function after the fact, and alwaysinline has similar correctness requirements.</div>
</div></div></div>