This is an archive of the discontinued LLVM Phabricator instance.

clang: Add __builtin_elementwise_fma
ClosedPublic

Authored by arsenm on Jan 4 2023, 7:18 AM.

Details

Summary

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.

Diff Detail

Event Timeline

arsenm created this revision.Jan 4 2023, 7:18 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 4 2023, 7:18 AM
arsenm requested review of this revision.Jan 4 2023, 7:18 AM
arsenm retitled this revision from clang: Add __builtin_elementsize_fma to clang: Add __builtin_elementwise_fma.Jan 4 2023, 7:20 AM

Need update clang/docs/ReleaseNotes.rst for new intrinsic.

bob80905 added inline comments.Jan 4 2023, 10:34 AM
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.
Is this intended behavior?

arsenm added inline comments.Jan 4 2023, 10:54 AM
clang/lib/Sema/SemaChecking.cpp
2629–2635

No? test/Sema/builtins-elementwise-math.c already checks all of these reject integers and passes

aaron.ballman added inline comments.Jan 10 2023, 10:51 AM
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?

RKSimon added inline comments.Jan 11 2023, 7:28 AM
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

arsenm marked an inline comment as done.Feb 23 2023, 3:59 AM
arsenm added inline comments.
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')}}
arsenm updated this revision to Diff 499805.Feb 23 2023, 4:00 AM

Loop merge, documentation

aaron.ballman accepted this revision.Feb 23 2023, 8:31 AM

LGTM!

clang/lib/Sema/SemaChecking.cpp
17881–17886

Oh, excellent, thank you!

This revision is now accepted and ready to land.Feb 23 2023, 8:31 AM