When constrained floating point is enabled the SystemZ-specific builtins don't use constrained intrinsics in some cases. Fix that.
A few comments (see inline) -- otherwise this looks good to me, thanks!
Spurious empty line.
Why is it that this one has metadata nodes and all the others do not? Do they really not have metadata (why?) or are you just not checking for them?
This was caused by unnecessary implicit conversions in the vecintrin.h code, I've now checked in cebba7c to remove those. Can you rebase? This FIXME should no longer be necessary.
What are the semantics of vfnmadb with respect to when it rounds vs the negation?
Hmm, interesting. The z/Architecture Principles of Operation states:
The results for each element of VECTOR FP NEGA-
TIVE MULTIPLY AND ADD and VECTOR FP NEGA-
TIVE MULTIPLY AND SUBTRACT are the same as
for VECTOR FP MULTIPLY AND ADD and VECTOR
FP MULTIPLY AND SUBTRACT, respectively, except
the sign bit of numeric results are inverted. When the
result is a NaN it’s sign bit is unchanged.
So as far as rounding is concerned, the vfnmadb should have the exact same result as a vfmadb ; vflcdb sequence we'd get from a fma/fneg.
I hadn't realized the NaN special treatment before. This makes the result actually different in that case. OTOH I guess IEEE only says the result has to some NaN, not particularly which NaN, so that's probably also OK. (In any case it's unrelated to strict FP.)
No reason, really. The regular expression will pick up the second metadata argument if present, so I could just eliminate the check for the second one here. This isn't a metadata test so precise testing of metadata arguments doesn't seem necessary? Consistency would be good, though.