[llvm-bugs] [Bug 45899] New: LLParser fails due to the "non-global-value-max-name-size" limit in Value.cpp

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=45899

            Bug ID: 45899
           Summary: LLParser fails due to the
                    "non-global-value-max-name-size" limit in Value.cpp
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM assembly language parser
          Assignee: unassignedbugs at nondot.org
          Reporter: mikael.holmen at ericsson.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 23478
  --> https://bugs.llvm.org/attachment.cgi?id=23478&action=edit
bbi-42804.ll reproducer

Reproduce with:
 opt -S -o - bbi-42804.ll

which gives

build-all-builtins/bin/opt: bbi-42804.ll:7:12: error: use of undefined value
'%for.body4.lr.ph.split.split.split.us18.split.split.for.body4.lr.ph.split.split.split.us18.split.split.split_crit_edge.i.split.split.for.body4.lr.ph.split.split.split.us18.split.split.for.body4.lr.ph.split.split.split.us18.split.split.split_crit_edge.i.split.split.split_crit_edge.i.split.split.for.body4.lr.ph.split.split.split.us18.split.split.for.body4.lr.ph.split.split.split.us18.split.split.split_crit_edge.i.split.split.for.body4.lr.ph.split.split.split.us18.split.split.for.body4.lr.ph.split.split.split.us18.split.split.split_crit_edge.i.split.split.split_crit_edge.i.split.split.split_crit_edge.i.split.split.for.body4.lr.ph.split.split.split.us18.split.split.for.body4.lr.ph.split.split.split.us18.split.split.split_crit_edge.i.split.split.for.body4.lr.ph.split.split.split.us18.split.split.for.body4.lr.ph.split.split.split.us18.split.split.split_crit_edge.i.split.split.split_crit_edge.i.split.split.for.body4.lr.ph.split.split.split.us18.split.split.for.body4.lr.ph.split.split.split.us18.split.split.split_crit7'

but the value it complains on is indeed defined in the input file.

If we instead do
 opt -S -o - bbi-42804.ll -non-global-value-max-name-size=1025
there is no error.

I don't know how things are supposed to work with the
"non-global-value-max-name-size" name limiit, but I think there is some
mismatch right now, where the LLParser doesn't consider that limit when it does
lookups in the symbol table in e.g LLParser::PerFunctionState::GetVal:

Value *LLParser::PerFunctionState::GetVal(const std::string &Name, Type *Ty,
                                          LocTy Loc, bool IsCall) {
  // Look this name up in the normal function symbol table.
  Value *Val = F.getValueSymbolTable()->lookup(Name);

  // If this is a forward reference for the value, see if we already created a
  // forward ref record.
  if (!Val) {
    auto I = ForwardRefVals.find(Name);
    if (I != ForwardRefVals.end())
      Val = I->second.first;
  }

  // If we have the value in the symbol table or fwd-ref table, return it.
  if (Val)
    return P.checkValidVariableType(Loc, "%" + Name, Ty, Val, IsCall);

  // Don't make placeholders with invalid type.
  if (!Ty->isFirstClassType()) {
    P.Error(Loc, "invalid use of a non-first-class type");
    return nullptr;
  }

  // Otherwise, create a new forward reference for this value and remember it.
  Value *FwdVal;
  if (Ty->isLabelTy()) {
    FwdVal = BasicBlock::Create(F.getContext(), Name, &F);
  } else {
    FwdVal = new Argument(Ty, Name);
  }

"Name" above is not truncated, so the

  Value *Val = F.getValueSymbolTable()->lookup(Name);

lookup tries to find the full name which fails even if it really shouldn't.
Then we create a new BasicBlock:
    FwdVal = BasicBlock::Create(F.getContext(), Name, &F);
but there it will be a collision in the symboltable so we use
ValueSymbolTable::makeUniqueName which will add a unique number to the end of
the name and then we get some mismatch where someone thinks we're jumping to a
basic block that doesn't exist.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200513/a5b5b4dc/attachment.html>