llvm dev - Mar 2014 - [LLVMdev] Some love for prune-as-you-go inlining.

Hey folks,

Could someone help me get this bug-fix into LLVM’s TOT?

CloneAndPruneFunctionInto: Fix pruned inlining when blockaddresses are present.

Details:
The issue is actually very simple: We were attempting to update
references to block address, but only the one's from blocks we had
seen so far.  In PruningFunctionCloner::CloneBlock, one block
is processed at a time, in a breadth first manner. This means that
our VMap, the instruction-remapping-mechanism, is also only updated
in an identical breadth first manner. In other words, if Block X
uses the address of Block Y, and Block Y has not yet been cloned,
then your instructions in Block X that reference the address of
Block Y will not be updated (so, they will refer to the old func's
Block Y, not the new func's block Y).


Jon


-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-fix-blockaddr.diff
Type: application/octet-stream
Size: 6033 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140325/187123a7/attachment.obj>

Please disregard. This is still a work in progress.


On Mar 25, 2014, at 2:25 PM, Jon McLachlan <mclachlan at apple.com> wrote:
> Hey folks,
> 
> Could someone help me get this bug-fix into LLVM’s TOT?
> 
> CloneAndPruneFunctionInto: Fix pruned inlining when blockaddresses are
present.
> 
> Details:
> The issue is actually very simple: We were attempting to update
> references to block address, but only the one's from blocks we had
> seen so far.  In PruningFunctionCloner::CloneBlock, one block
> is processed at a time, in a breadth first manner. This means that
> our VMap, the instruction-remapping-mechanism, is also only updated
> in an identical breadth first manner. In other words, if Block X
> uses the address of Block Y, and Block Y has not yet been cloned,
> then your instructions in Block X that reference the address of
> Block Y will not be updated (so, they will refer to the old func's
> Block Y, not the new func's block Y).
> 
> 
> Jon
> 
> 
>
<llvm-fix-blockaddr.diff>_______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev