[NFC][Clang][CodeGen] Remove vestigial assertion

[AlexVlx]

This removes a vestigial assertion, which would erroneously trigger even though we now correctly handle valid arg mismatches (

llvm-project/clang/lib/CodeGen/CGCall.cpp

Line 5397 in 2dda529

// The only plausible mismatch here would be for pointer address spaces,

), after #114062 went in.

[llvmbot]

@llvm/pr-subscribers-clang

Author: Alex Voicu (AlexVlx)

Changes

This removes a vestigial assertion, which would erroneously trigger even though we now correctly handle valid arg mismatches (<

llvm-project/clang/lib/CodeGen/CGCall.cpp

Line 5397 in 2dda529

// The only plausible mismatch here would be for pointer address spaces,

>), after #114062 went in.

---

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

1 Files Affected:

• (modified) clang/lib/CodeGen/CGCall.cpp (-16)

diff --git a/clang/lib/CodeGen/CGCall.cpp b/clang/lib/CodeGen/CGCall.cpp
index e6c2ac939eb88..47bfd470dbafb 100644
--- a/clang/lib/CodeGen/CGCall.cpp
+++ b/clang/lib/CodeGen/CGCall.cpp
@@ -5633,22 +5633,6 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo &CallInfo,
   if (!CallArgs.getCleanupsToDeactivate().empty())
     deactivateArgCleanupsBeforeCall(*this, CallArgs);
 
-  // Assert that the arguments we computed match up.  The IR verifier
-  // will catch this, but this is a common enough source of problems
-  // during IRGen changes that it's way better for debugging to catch
-  // it ourselves here.
-#ifndef NDEBUG
-  assert(IRCallArgs.size() == IRFuncTy->getNumParams() || IRFuncTy->isVarArg());
-  for (unsigned i = 0; i < IRCallArgs.size(); ++i) {
-    // Inalloca argument can have different type.
-    if (IRFunctionArgs.hasInallocaArg() &&
-        i == IRFunctionArgs.getInallocaArgNo())
-      continue;
-    if (i < IRFuncTy->getNumParams())
-      assert(IRCallArgs[i]->getType() == IRFuncTy->getParamType(i));
-  }
-#endif
-
   // Update the largest vector width if any arguments have vector types.
   for (unsigned i = 0; i < IRCallArgs.size(); ++i)
     LargestVectorWidth = std::max(LargestVectorWidth,

[llvmbot]

@llvm/pr-subscribers-clang-codegen

Author: Alex Voicu (AlexVlx)

Changes

This removes a vestigial assertion, which would erroneously trigger even though we now correctly handle valid arg mismatches (<

llvm-project/clang/lib/CodeGen/CGCall.cpp

Line 5397 in 2dda529

// The only plausible mismatch here would be for pointer address spaces,

>), after #114062 went in.

---

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

1 Files Affected:

• (modified) clang/lib/CodeGen/CGCall.cpp (-16)

diff --git a/clang/lib/CodeGen/CGCall.cpp b/clang/lib/CodeGen/CGCall.cpp
index e6c2ac939eb88..47bfd470dbafb 100644
--- a/clang/lib/CodeGen/CGCall.cpp
+++ b/clang/lib/CodeGen/CGCall.cpp
@@ -5633,22 +5633,6 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo &CallInfo,
   if (!CallArgs.getCleanupsToDeactivate().empty())
     deactivateArgCleanupsBeforeCall(*this, CallArgs);
 
-  // Assert that the arguments we computed match up.  The IR verifier
-  // will catch this, but this is a common enough source of problems
-  // during IRGen changes that it's way better for debugging to catch
-  // it ourselves here.
-#ifndef NDEBUG
-  assert(IRCallArgs.size() == IRFuncTy->getNumParams() || IRFuncTy->isVarArg());
-  for (unsigned i = 0; i < IRCallArgs.size(); ++i) {
-    // Inalloca argument can have different type.
-    if (IRFunctionArgs.hasInallocaArg() &&
-        i == IRFunctionArgs.getInallocaArgNo())
-      continue;
-    if (i < IRFuncTy->getNumParams())
-      assert(IRCallArgs[i]->getType() == IRFuncTy->getParamType(i));
-  }
-#endif
-
   // Update the largest vector width if any arguments have vector types.
   for (unsigned i = 0; i < IRCallArgs.size(); ++i)
     LargestVectorWidth = std::max(LargestVectorWidth,

[jhuber6]

Makes sense, since this is only for these call arguments which are handled in all cases now I presume.

[arsenm]

Missing test for the case where this broke?

[tstellar]

Does this fix need to be backported?

[jhuber6]

The fix will need to be backported, but I don't think this fixed it all the way so we'll need another follow-up.

[tstellar]

@jhuber6 Was the follow-up for this backported too?

[jhuber6]

@jhuber6 Was the follow-up for this backported too?

I don't remember, sorry. I think the whole thing got reverted or something?