DAGTypeLegalizer::RemapValue failure


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

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.