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>