<div dir="ltr">On Sun, Jun 23, 2013 at 10:57 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">> This does conflict with the theoretical separation of concerns between<br>

> optimizer and codegen in LLVM though. This patch does not promote subsequent<br>
> mid-level optimization opportunities; treating values as live when they are<br>
> actually unused may actually obscure other mid-level optimization<br>
> opportunities.<br>
><br>
> Dan<br>
><br>
<br>
</div>I understand, and I'm not thrilled about it either, but is there an<br>
alternative course of action you can think of? The problem is that the<br>
return value provides potentially valuable information, and there's no<br>
good way (as far as I can tell) to get it back at the CodeGen level if<br>
it's dropped from the IR because it would require interprocedural<br>
coordination of code generation.<br></blockquote><div><br></div><div>No, I don't have any alternatives, other than interprocedural coordination of code generation. Do you have any alternatives?</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

Also, in theory, some mid level optimization could be done, even if it<br>
is not done now. A 'returned' argument implies the argument and return<br>
value are aliases of each other in all code dominated by the function<br>
call, so IR optimizers would be free to replace one with the other. As<br>
mentioned in other e-mails, it is, the problem is that, in the general<br>
case, it is difficult to know which alternative to pick; however, an<br>
IR pass could, at a minimum, canonicalize this:<br>
<br>
  %struct.A = type { i32 }<br>
<br>
  declare %struct.A* @a_ctor(%struct.A* returned)<br>
  declare void @bar(%struct.A*)<br>
<br>
  define %struct.A* @foo() {<br>
  entry:<br>
    %a = alloca %struct.A, align 4<br>
    %b = call %struct.A* @a_ctor(%struct.A* %a)<br>
    call void @bar(%struct.A* %a)<br>
    ret %struct.A* %b<br>
  }<br></blockquote><div><br></div><div>The canonical form would be:</div><div><br></div><div>%struct.A = type { i32 }<br><br>  declare %struct.A* @a_ctor(%struct.A* returned)<br>  declare void @bar(%struct.A*)<br><br>  define %struct.A* @foo() {<br>
  entry:<br>    %a = alloca %struct.A, align 4<br>    %b = call %struct.A* @a_ctor(%struct.A* %a)<br>    call void @bar(%struct.A* %a)<br>    ret %struct.A* %a<br>  }<br></div><div><br></div><div>In other words, it's advantageous to see the actual value, and there's no mid-level optimizer benefit to seeing the return value.</div>
<div><br></div><div>Dan</div><div><br></div></div></div></div>