<div dir="ltr">On Tue, Jun 25, 2013 at 9:09 AM, Stephen Lin <span dir="ltr"><<a href="mailto:swlin@post.harvard.edu" target="_blank">swlin@post.harvard.edu</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>On Tuesday, June 25, 2013, Dan Gohman wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Even with smarter heuristics, you're still breaking mid-level optimizations in some cases. I think the fact that you're trying to represent the return value at the IR at all is awkward. </div>
</blockquote><div> </div></div><div>I'm not sure what those cases are. The 'returned' attribute<span></span> will not keep a return value alive if the argument would be dead otherwise, so it's not preventing further dead arg elimination (the argument marked with 'returned' would not be eliminated even if the return value were to be because its being used for something else.)</div>
<div><br></div><div>The only possible benefit I could think of is if the argument were only live in the very beginning of the function and dead for the rest of it other than being used for the return value. At that case it's costing a single spill in the very worst case, as far as I can tell. I can't think of a mid-level optimization that would be affected.</div>
</blockquote><div><br></div><div>Here's an attempt at an example to make this more concrete, though I'm not completely sure we're talking about the same case:</div><div><br></div><div>define i8* @foo(i8* returned %a) {</div>
<div> call void @do_stuff_that_does_not_use_a();</div>
<div> ret i8* %a<br>}</div><div><br></div><div>...</div><div>%x = expensive_thing</div><div>%t = call i8* @foo(i8* %x)</div><div>... (further uses of %x that may eventually be discovered to be dead)</div><div><br></div>
<div>If %x is ultimately dead, how do we get to the point of removing it? It's not trivially dead because it has a use. If you teach dead-arg elimination to keep it live, then it won't die even if its other uses are ultimately removed.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
It'd be more natural to have the function return void, and treat it specially in codegen. I propose the following alternative.</div><div>
<div dir="ltr"><div>
<div><br></div><div>Keep the 'returned' argument attribute, and add a 'returnsarg' function attribute. Then, the semantics of 'returned' are that it is ignored unless it is the first 'returned' argument in a function that is marked 'returnsarg' and has a void return type. Then at the codegen level, the function is translated as if it had the return type of its first 'returned' argument. As an optimization, codegen can rewrite uses after the call to use the return value.</div>
<div><br></div><div>That way, DeadArgElimination and all the other mid-level optimizations can run at full strength, and you can still get your optimization. What do you think?</div><div><br></div><div>Dan</div><div><div class="gmail_extra">
<br></div></div></div></div></div></blockquote><div><br></div><div>But the callee actually has to return that argument somehow for the attribute to be valid. Are you proposing that the functions marked with 'returnsarg' silently save an argument and return it in codegen without actually representing that return in IR? If so, there's no benefit to taking away the return value because code gen is going to have to keep track of it somehow anyway to return it, and it will have to have special machinery to do so in a way that doesn't waste an extra register unnecessarily (it's not like a normal callee saved register because the value is also going to be used in the body of the function)</div>
</blockquote><div><br></div><div>Yes. I'm suggesting this because the optimization you're proposing really is a low-level calling convention optimization that doesn't conceptually belong in the mid-level optimizer as more than attributes.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br></div><div>Also, just because the return value is unused at the IR level in this case doesn't meant it won't ever be used. You could canonicalize the IR to remove uses of the return value if you wanted to, but how does a front end express code before it is canonicalized?</div>
</blockquote><div><br></div><div>The front-end would just emit uses of the outgoing argument from the caller. WRT memcpy, LLVM's memcpy intrinsic has a void return type already, for example, so this is something you'd want to figure out anyway.</div>
<div><br></div><div>Dan</div><div><br></div></div></div></div>