[PATCH] D153722: [LLParser] Friendly error out if a non global value's name exceeds max name size

Han Yulong via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 27 04:03:18 PDT 2023


wheatfox added inline comments.


================
Comment at: llvm/lib/AsmParser/LLParser.cpp:3447
+
+    if (InstNameSize != NameStrSize + 1) {
+      // The name is too long and was trimmed when stored in SmallString with
----------------
wheatfox wrote:
> nikic wrote:
> > So this is based on the assumption that in the "multiple definition" case the name will always be `%name0`? This seems a bit fragile (I'm not entirely confident it is true, and we can't reach a counter with more than one digit here). Is it possible to check InstNameSize < NameStrSize instead?
> according to `createValueName` and `makeUniqueName`, if we have a code of
> ```
>   %var = add i32 0, 1
>   %var = alloca i32, align 4
> ```
> then the first `var` will be fine, but the second `var` will be appended a counter `S << ++LastUnique` in `makeUniqueName`, so it will store `var1` as the value's name. Then the parser throws the "multiple definition" error immediately, so this suffix `1` will only exist for once(and also for a short time since the error will be thrown at once).
> 
> Moreover. I agree that `InstNameSize < NameStrSize` will be more intuitive for "name size overflowed". If `InstNameSize != NameStrSize + 1` and obviously `InstNameSize != NameStrSize`(considering the first if `Inst->getName() != NameStr`, if the size are the same, then the two strings should be exactly the same), then `InstNameSize < NameStrSize` exactly matches the case. I will update my diff later :)
I also found another issue:
```
define void @f() {
bb0:
  %var.1 = alloca i32, align 4
  %var.11 = alloca i32, align 4
  ret void
}
```
this code will sucessfully run when max name size is set to `5`, even if `var.11` has size of `6`. This is because `var.11` was first trimmed to `var.1` due to `5`'s limit, and then `makeUniqueName` append `1` to its end. Finally we got `var.11` again, which passed the `Inst->getName() != NameStr` since the actual `var.11` equals the new name `var.11``. I will consider this along with my patch.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D153722/new/

https://reviews.llvm.org/D153722



More information about the llvm-commits mailing list