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

Duncan P. N. Exon Smith via llvm-commits llvm-commits at lists.llvm.org
Tue Apr 5 19:33:11 PDT 2016


> 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!


More information about the llvm-commits mailing list