[LLVMdev] DAGTypeLegalizer::RemapValue failure

[Nadav Rotem]

Hi Anat, 

The assertion needs to be there.  This bug happens when a value is returned from the type-legalizer handlers, and is RAUW (replace-all-uses-with).  The values to be replaced are saved in CSE map. Often, changing these value trigger additional RAUW calls. The RAUW invocations call the type-legalizer callback which need to manage the node state (new/analyzed/etc).  The problem is that multiple invocation of RAUW (due to CSE changes) sometimes keep the type-legalizer data-structure in an unstable state. I don't know of an easy fix to the problem. Here is a quick workaround: When you are type-legalizing values,  try not to use the old un-legalized values. I found that this reduces the cases in which these bugs occur.  

Nadav


On Aug 16, 2012, at 11:39 PM, "Shemer, Anat" <anat.shemer at intel.com> wrote:

> Hi,
>  
> If you are familiar with LegalizeTypes I will be glad if you can help me with the following scenario.
>  
> I’m debugging some ll test that fails with an assertion in “void DAGTypeLegalizer::RemapValue(SDValue &N)” because it does not expect that a remap to a new node exists.
>  
> However looking at the code for a while this seems to be a valid case. I see that many times nodes are added to ReplacedValues map as a value when their NodeID is 0, and therefore they might become a NewNode later. As soon as they become NewNode they are analyzed in AnalyzeNewNode() and in this process, which recurs through the new node operands, it’s possible to reach RemapValue and find there the node as a NewNode. That’s the scenario in which my test fails.
>  
> But I probably miss something because normally this assertion is not hit.
>  
> Is this assertion correct?
> What is wrong with the scenario that I describe? Or why doesn’t it happen more often?
>  
> BTW, I searched in LLVM archives and saw that this assertion was removed in 2008 but returned later. but I couldn’t find an explanation how this should work.
>  
> Thanks, Anat
>  
>  
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120817/cf6dc46a/attachment.html>