[llvm] r265273 - ValueMapper: Avoid recursion in mapSimplifiedMetadata, NFC

[Richard Trieu via llvm-commits]

And thank you for the quick fix!

On Tue, Apr 5, 2016 at 7:33 PM, Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:

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