<div dir="ltr">Right, that's another (more aggressive) way. I am not against that either. <div><div><br></div><div>Jingyue</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 5, 2014 at 2:22 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 5 June 2014 17:01, Jingyue Wu <<a href="mailto:jingyue@google.com">jingyue@google.com</a>> wrote:<br>

> Hi Phillip,<br>
><br>
> Thanks for your comments! They do make a lot of sense.<br>
><br>
> I wasn't here when the addrspacecast instruction was added. Maybe Matt can<br>
> provide more context on why addrspacecast is a superset of bitcast. However,<br>
> I don't see too much value of including the semantics of bitcast besides<br>
> making bitcode more compact.<br>
><br>
> With that, I would be more than happy to work on having clang emitting both<br>
> of them. But even with changes in clang, I think instcombine would still<br>
> need this canonicalization to handle IR not directly generated by clang.<br>
<br>
</div>If desirable, we could change the IR to require addrspacecast to<br>
change just the address space and then move this logic to the bitcode<br>
upgrade.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div>