Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Clang] Fix a non-effective assertion #81083

Merged
merged 1 commit into from
Feb 8, 2024

Conversation

shiltian
Copy link
Contributor

@shiltian shiltian commented Feb 8, 2024

PTy here is literally FTy->getParamType(i), which makes this assertion not
work as expected.

`PTy` here is literally `FTy->getParamType(i)`, which makes this assertion not
work as expected.
@llvmbot llvmbot added clang Clang issues not falling into any other category clang:codegen labels Feb 8, 2024
@llvmbot
Copy link
Collaborator

llvmbot commented Feb 8, 2024

@llvm/pr-subscribers-clang

Author: Shilei Tian (shiltian)

Changes

PTy here is literally FTy->getParamType(i), which makes this assertion not
work as expected.


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

1 Files Affected:

  • (modified) clang/lib/CodeGen/CGBuiltin.cpp (+1-1)
diff --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index e051cbc6486353..a7a410dab1a018 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -5908,7 +5908,7 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl GD, unsigned BuiltinID,
           }
         }
 
-        assert(PTy->canLosslesslyBitCastTo(FTy->getParamType(i)) &&
+        assert(ArgValue->getType()->canLosslesslyBitCastTo(PTy) &&
                "Must be able to losslessly bit cast to param");
         // Cast vector type (e.g., v256i32) to x86_amx, this only happen
         // in amx intrinsics.

@llvmbot
Copy link
Collaborator

llvmbot commented Feb 8, 2024

@llvm/pr-subscribers-clang-codegen

Author: Shilei Tian (shiltian)

Changes

PTy here is literally FTy->getParamType(i), which makes this assertion not
work as expected.


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

1 Files Affected:

  • (modified) clang/lib/CodeGen/CGBuiltin.cpp (+1-1)
diff --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index e051cbc6486353..a7a410dab1a018 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -5908,7 +5908,7 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl GD, unsigned BuiltinID,
           }
         }
 
-        assert(PTy->canLosslesslyBitCastTo(FTy->getParamType(i)) &&
+        assert(ArgValue->getType()->canLosslesslyBitCastTo(PTy) &&
                "Must be able to losslessly bit cast to param");
         // Cast vector type (e.g., v256i32) to x86_amx, this only happen
         // in amx intrinsics.

@@ -5908,7 +5908,7 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl GD, unsigned BuiltinID,
}
}

assert(PTy->canLosslesslyBitCastTo(FTy->getParamType(i)) &&
assert(ArgValue->getType()->canLosslesslyBitCastTo(PTy) &&
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there much point to this assertion, given that the BitCast constructor will also assert castIsValid? canLosslesslyBitCastTo looks arbitrarily different from castIsValid

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

canLosslesslyBitCastTo is supposed to be stricter than castIsValid but it looks too conservative. For example, it doesn't allow bitcast between float and int.

@shiltian shiltian merged commit c4b0dfc into llvm:main Feb 8, 2024
7 checks passed
@shiltian shiltian deleted the always_true_assertion branch February 8, 2024 14:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clang:codegen clang Clang issues not falling into any other category
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants