<div dir="ltr">On 22 May 2013 11:44, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</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 class="im">> where %group must be the result of a call to llvm.load.group. Any two loads<br>
> with the same %group value are known to produce the same value. We can then<br>
> choose to eliminate the latter of the loads as redundant in GVN, or in the<br>
> event of high register pressure we could choose to reload without spilling<br>
> to the stack.<br>
<br>
</div>What mark would GVN leave on the IR for the register allocator to use<br>
when rematerializing the load?<br></blockquote><div><br></div><div style>It's something novel we would have to create, probably by slapping metadata on the load.</div><div style><br></div><div style>This proposal is dead, in favour of my newer proposal for @llvm.newobject (in the same thread). That proposal is stalled because it relies on picking a certain interpretation of the C++ standard in an area where the standard is self-contradictory.</div>

<div style><br></div><div style>There are other issues in devirtualization which I can make progress on (PR11331 is one, and "knowing the initial value of the vtable post-constructor where the constructor is not defined in this translation unit" is another), but I think I need to drop the category of "same pointer implies same vtable" optimizations until there are language changes that support it.</div>

<div style><br></div><div style>Nick</div><div style><br></div></div></div></div>