I didn't understand why the other builtins have promotion logic,
or how it would apply for a ternary operation. Implicit conversions
are evil to begin with, and even more so when the purpose is to get
an exact IR intrinsic. This checks all the arguments have the same type.
Details
Diff Detail
Unit Tests
Event Timeline
clang/lib/Sema/SemaChecking.cpp | ||
---|---|---|
2629–2635 | This change appears to allow more types (such as integers) as args for this set of builtins in the above cases, where before the behavior was to just allow floats. |
clang/lib/Sema/SemaChecking.cpp | ||
---|---|---|
2629–2635 | No? test/Sema/builtins-elementwise-math.c already checks all of these reject integers and passes |
clang/lib/Sema/SemaChecking.cpp | ||
---|---|---|
2629–2635 | As best I can tell, it actually allows *less* types. The old code was calling !EltTy->isFloatingType() and the new code is calling !EltTy->isRealFloatingType(), so the old code would allow a complex float while the new code prohibits it. Is that intentional? We should add some explicit test coverage for how these builtins work with complex types. | |
17881–17886 | This will cause conversions to happen *before* we check whether the types are the same; is that expected? e.g., it seems like this would allow you to pass a float and a double and thanks to the magic of usual unary conversions they both come out as double and thus don't get diagnosed. | |
17895–17905 | These two loops can be merged together, right? |
clang/docs/LanguageExtensions.rst | ||
---|---|---|
634 | (trivial) improve the operation description to make it clear the fma order - I guess most devs will assume "(x*y)+z" but it'd be good to be explicit here |
clang/lib/Sema/SemaChecking.cpp | ||
---|---|---|
2629–2635 | There already are complex tests for these. For some reason the type check was split between here and checkMathBuiltinElementType through PrepareBuiltinElementwiseMathOneArgCall | |
17881–17886 | The tests say that isn't happening, e.g. here: f32 = __builtin_elementwise_fma(f64, f32, f32); // expected-error@-1 {{arguments are of different types ('double' vs 'float')}} f32 = __builtin_elementwise_fma(f32, f64, f32); // expected-error@-1 {{arguments are of different types ('float' vs 'double')}} |
(trivial) improve the operation description to make it clear the fma order - I guess most devs will assume "(x*y)+z" but it'd be good to be explicit here