[TableGen] Avoid repeated hash lookups (NFC)

[kazutakahirata]

No description provided.

[llvmbot]

@llvm/pr-subscribers-tablegen

Author: Kazu Hirata (kazutakahirata)

Changes

---

Full diff: https://github.com/llvm/llvm-project/pull/120681.diff

1 Files Affected:

• (modified) llvm/utils/TableGen/Common/CodeGenDAGPatterns.cpp (+1-2)

diff --git a/llvm/utils/TableGen/Common/CodeGenDAGPatterns.cpp b/llvm/utils/TableGen/Common/CodeGenDAGPatterns.cpp
index 1a393beaa14f96..7a82581f2240ce 100644
--- a/llvm/utils/TableGen/Common/CodeGenDAGPatterns.cpp
+++ b/llvm/utils/TableGen/Common/CodeGenDAGPatterns.cpp
@@ -3508,9 +3508,8 @@ void CodeGenDAGPatterns::FindPatternInputsAndOutputs(
         Val->getDef()->isSubClassOf("PointerLikeRegClass")) {
       if (Dest->getName().empty())
         I.error("set destination must have a name!");
-      if (InstResults.count(Dest->getName()))
+      if (!InstResults.try_emplace(Dest->getName(), Dest).second)
         I.error("cannot set '" + Dest->getName() + "' multiple times");
-      InstResults[Dest->getName()] = Dest;
     } else if (Val->getDef()->isSubClassOf("Register")) {
       InstImpResults.push_back(Val->getDef());
     } else {

[mshockwave]

Your patch nerd-sniped me because with your change, technically InstResults will store a different value -- the original destination register rather than the one that comes after -- upon running into collision key, since I.error(...) won't bail out from the execution. However, I think even the flow won't stop right away with this ill-formed tree pattern instance, it will eventually top at the type inference stage that follows.

[kazutakahirata]

Your patch nerd-sniped me because with your change, technically InstResults will store a different value -- the original destination register rather than the one that comes after -- upon running into collision key, since I.error(...) won't bail out from the execution. However, I think even the flow won't stop right away with this ill-formed tree pattern instance, it will eventually top at the type inference stage that follows.

Good point! Let me use insert_or_assign instead. I don't want to introduce subtlety here.

[kazutakahirata]

@mshockwave I've updated the patch. Please take a look. Thanks!

[mshockwave]

Much better, thanks