This is an archive of the discontinued LLVM Phabricator instance.

[LLParser] Friendly error out if a non global value's name exceeds max name size
Needs ReviewPublic

Authored by wheatfox on Jun 25 2023, 7:58 AM.

Details

Reviewers
nikic
tejohnson
Summary

The previous implementation of LLParser.cpp will error out
multiple definition of local value when %var = ... exceeds max length(when set to 2). However, the real error is name size exceeding. Therefore, I added some code to correctly error out that reason instead of "multiple definition".

Diff Detail

Event Timeline

wheatfox created this revision.Jun 25 2023, 7:58 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 25 2023, 7:58 AM
wheatfox requested review of this revision.Jun 25 2023, 7:58 AM
wheatfox updated this revision to Diff 534337.Jun 25 2023, 8:08 AM

update llvm\test\Assembler\non-global-value-max-name-size.ll and add llvm-as test

wheatfox updated this revision to Diff 534405.Jun 25 2023, 7:01 PM

designed a new test in \llvm\test\Assembler\non-global-value-max-name-size-2.ll, and used llvm-lit to run the new test locally to make sure that things work fine.

wheatfox set the repository for this revision to rG LLVM Github Monorepo.Jun 26 2023, 9:51 PM
nikic added inline comments.Jun 27 2023, 12:56 AM
llvm/lib/AsmParser/LLParser.cpp
3447

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?

wheatfox added inline comments.Jun 27 2023, 3:17 AM
llvm/lib/AsmParser/LLParser.cpp
3447

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 :)

wheatfox added inline comments.Jun 27 2023, 4:03 AM
llvm/lib/AsmParser/LLParser.cpp
3447

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.

wheatfox added inline comments.Jun 27 2023, 4:24 AM
llvm/lib/AsmParser/LLParser.cpp
3447
define void @f() {
bb0:
  %varname = alloca i32, align 4
  %varname2 = add i32 0, 1
  ret void
}

According to the new found issue, in the case above (max name size=7) while varname2 was trimmed into varname and conflicts the first varname, the Inst->getName() will be varname1 which will be the same size of NameStr, Therefore, only InstNameSize != NameStrSize + 1 will work.

wheatfox updated this revision to Diff 534911.Jun 27 2023, 4:38 AM

considered another scene where potential name size exceeding would happen

wheatfox updated this revision to Diff 535230.Jun 27 2023, 9:44 PM

cleanup the comments