On Fri, 26 May 2017, Richard Biener wrote:
Similarly, I
don't see div as a builtin in that file, only FILE* has special code, but
that doesn't seem worth the trouble here. So I am only declaring the 5
"simple" functions, with minimal properties: leaf, nothrow, and for
fegetround pure (glibc already declares it that way). We can then discuss
the safety of future optimizations on a case by case basis.
+DEF_C99_BUILTIN (BUILT_IN_FERAISEEXCEPT, "feraiseexcept",
BT_FN_INT_INT, ATTR_NOTHROW_LEAF_LIST)
I think feraiseexcept shouldn't be nothrow?
glibc marks it as nothrow. I can remove the nothrow flag for now, for
safety. It may trap, but it does not throw a C++ exception AFAIU.
Also with -fnon-call-exceptions?
Hmm, maybe on windows where trap handlers turn into system exceptions
which are handled like C++ exceptions... I am happy to remove nothrow.
But it may be pure.
It writes to the exception register (aka memory for now), so I would hardly
call it pure.
But it doesn't have to be ordered with control word writes/reads, no?
Not sure what you mean here. feraiseexcept(FE_DIVBYZERO) is equivalent to
1./0., it writes to the exception status flag. Its order with
respect to fetestexcept must be preserved.
Likewise fetestexcept may be pure?
Too unsafe for now, since any FP operation can write to the memory that
fetestexcept reads.
Ah... but then FP operations are not ordered with the builtins anyway,
only FP loads/stores would be.
Since gcc doesn't handle fenv properly, people have been using a number of
workarounds, in particular with pass-through asm, sometimes volatile,
occasionally with the "memory" clobber.
Some of those versions would still work with pure, but the attribute
increases the likelyhood of breaking some of those uses, and I don't know
if it would ever help in practice, so I would rather not add it for now.
fegetround is very different since it can safely swap position with an
adjacent float operation.
After all having builtins is only the first easiest step of properly modeling
dependences between FP ops and the FP control/exception registers.
Yes, I didn't expect adding those 5 builtins (modulo the nothrow flag) to
be controversial...
--
Marc Glisse
