shiltian wrote: > I can't tell what you're trying to fix here. Is this fixing a crash? Or is > the check redundant? Or is it necessary for some followup change you want to > make?
Sorry, I should have clearly mentioned that. Yes, it is for my followup change #80908. In #80908, we changed the type of LLVM builtin but kept the corresponding clang builtin unchanged to avoid breaking existing uses. Specifically, the original builtin accepts some `bfloat` arguments (either `bfloat` or `<2 x bfloat>`) and returns a `bfloat` value. Because of some historic reasons, the builtin uses `i16` to represent `bfloat` values, and the backend just treats the 16 bits as `bfloat`. Now we encountered some issues that motivated us to use the right type here, but we still want to maintain sort of backward compatibility, at least on user-facing level. Keeping the corresponding clang builtin unchanged is the path we chose. Given that, it requires the front end to emit corresponding bitcast because the type `i16` and `bfloat` (and the vec type) are not matched. `EmitBuiltinExpr` is capable of doing that, but the bitcast check here prevents it from doing it. `canLosslesslyBitCastTo` doesn't think bitcast from `i16` to `bf16` and vice versa are lossless. I was thinking of just allowing this specific cast in `canLosslesslyBitCastTo` but I figured that doesn't look very good. On a second thought, it looks like the check here is too conservative. https://github.com/llvm/llvm-project/pull/81669 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
