<div dir="ltr">And thank you for the quick fix!</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 5, 2016 at 7:33 PM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.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="HOEnZb"><div class="h5"><br>
> On 2016-Apr-05, at 18:11, Richard Trieu <<a href="mailto:rtrieu@google.com">rtrieu@google.com</a>> wrote:<br>
><br>
> On Sun, Apr 3, 2016 at 1:17 PM, Duncan P. N. Exon Smith via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br>
> Author: dexonsmith<br>
> Date: Sun Apr  3 15:17:45 2016<br>
> New Revision: 265273<br>
><br>
> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=265273&view=rev" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project?rev=265273&view=rev</a><br>
> Log:<br>
> ValueMapper: Avoid recursion in mapSimplifiedMetadata, NFC<br>
><br>
> The main change is to delay materializing GlobalValue initializers from<br>
> Mapper::mapValue until Mapper::~Mapper.  This effectively removes all<br>
> recursion from mapSimplifiedMetadata, as promised in r265270.<br>
> mapSimplifiedMetadata calls mapValue for ConstantAsMetadata nodes to<br>
> find the mapped constant, and now it shouldn't be possible for mapValue<br>
> to indirectly re-invoke mapMetadata.  I'll add an assertion to that<br>
> effect in a follow-up (separated so that the assertion can easily be<br>
> reverted independently, if it comes to that).<br>
><br>
> This a step toward a broader goal: converting Mapper::mapMetadataImpl<br>
> from a recursive to an iterative algorithm.<br>
><br>
> When a BlockAddress points at a BasicBlock inside an unmaterialized<br>
> function body, we need to delay it until the function body is<br>
> materialized in Mapper::~Mapper.  This commit creates a temporary<br>
> BasicBlock and returns a new BlockAddress, then RAUWs the BasicBlock<br>
> once it is known.  This situation should be extremely rare since a<br>
> BlockAddress is usually used from within the function it's referencing<br>
> (and BlockAddress itself is rare).<br>
><br>
> There should be no observable functionality change.<br>
><br>
> Modified:<br>
>     llvm/trunk/lib/Transforms/Utils/ValueMapper.cpp<br>
><br>
> Hi Duncan,<br>
><br>
> A segfault while compiling at -O2 was first seen at this revision.  Can you take a look at <a href="https://llvm.org/bugs/show_bug.cgi?id=27233" rel="noreferrer" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=27233</a> ?<br>
<br>
</div></div>Should be fixed as of r265508.  Thanks for tracking this down!</blockquote></div><br></div>