[LLVMdev] TableGen and DenseMap Strangeness

[David Greene]

In the midst of making TableGen Inits unique, I've run into some very
odd DenseMap behavior.

I converted the TernOpInit to use a factory method that uses a DenseMap
to unique objects.  I have defined a DenseMapInfo for std::string that
uses HashString from StringExtras.h.

const TernOpInit *TernOpInit::get(TernaryOp opc, const Init *lhs,
                                  const Init *mhs, const Init *rhs,
                                  RecTy *Type) {
#define WORKS
#ifdef WORKS
  typedef std::pair<
    std::pair<
      std::pair<std::pair<unsigned, std::string>, const Init *>,
      const Init *
      >,
    const Init *
    > Key;
#else
  typedef std::pair<
    std::pair<
      std::pair<std::pair<unsigned, const Init *>, const Init *>,
      const Init *
      >,
    std::string
    > Key;
#endif

  typedef DenseMap<Key, TernOpInit *> Pool;
  static Pool ThePool;

#ifdef WORKS
  Key TheKey(std::make_pair(std::make_pair(std::make_pair(std::make_pair(opc,
                                                                         Type->getAsString()),
                                                          lhs),
                                           mhs),
                            rhs));
#else
  Key TheKey(std::make_pair(std::make_pair(std::make_pair(std::make_pair(opc,
                                                                         lhs),
                                                          mhs),
                                           rhs),
                            Type->getAsString()));
#endif

  Pool::iterator Result = ThePool.find(TheKey);

  if (Result == ThePool.end()) {
    TernOpInit *New = new TernOpInit(opc, lhs, mhs, rhs, Type);
    bool Inserted = false;
    tie(Result, Inserted) = ThePool.insert(std::make_pair(TheKey, New));
    assert(Inserted && "Did not insert new Init into pool!");
  }

  return Result->second;
}

If WORKS is defined, everything builds and tests fine.  If it is not
defined, TableGen aborts with:

lib/Target/X86/X86InstrFPStack.td:212:10: error: In SUBR_FpI16m80: Operand $src1 does not appear in the instruction pattern
defm SUBR: FPBinary<fsub ,MRM5m, "subr">;
         ^

Anyone have a clue why the order of hashing might matter?  I've made
sure no Inits are deleted anywhere so their memory should not be reused.
Valgrind reports a "clean" run aside from the gargantuan amount of
memory leaks.

Thanks for your help!

                                    -Dave