On Tue, 30 Jul 2013, Andrew MacLeod wrote:
> > A flag on the expression could indicate that the floating-point semantics
> > are required. I'd guess back ends would need to provide three insn
> > patterns, corresponding to feholdexcept, feclearexcept and feupdateenv,
> > that there'd be corresponding built-in functions for these used at
> > gimplification time, and that a target hook would give the type used for
> > fenv_t by these built-in functions (*not* necessarily the same as the
> > fenv_t used by any implementation of the functions in libm). The target
> > should also be able to declare that there's no support for floating-point
> > exceptions (e.g. for soft-float) and so floating-point cases don't need
> > any special handling.
> >
> I think the fact that it requires floating point sematics should be
> determinable from the types of the expressions involved. If there is a
My reasoning for such a flag is:
The gimplifier shouldn't need to know the details of the semantics for
operand promotions, how various arithmetic on complex numbers is carried
out, and how a result is converted back to the destination type for the
store. Even if it's the language-specific gimplification code rather than
the language-independent gimplifier, we still want those details to be in
one place (currently build_binary_op for the binary operation semantics),
shared by atomic and non-atomic operations.
Hence my suggestion that the operands to the new built-in function /
operation do not include the unmodified RHS, and do not directly specify
the operation in question. Instead, one operand is an expression of the
form
(convert-to-LHS-type) (old op val)
where "old" and "val" are the temporary variables given in C11 footnote
113 and probably allocated by the front end ("val" initialized once, "old"
initialized once but then potentially changing each time through the
loop). The trees for that expression would be generated by
build_binary_op and contain everything required for the semantics of e.g.
complex arithmetic.
It's true that in the case where floating-point issues arise,
floating-point types will be involved somewhere in this expression (and
otherwise, they will not be - though the initializer for "val" might
itself have involved floating-point arithmetic), but you'd need to search
recursively for them; having a flag seems simpler.
> THis also means that for the 3 floating point operations all we need are RTL
> insn patterns, no buitin. And as with the other atomics, if the pattern
I think something will also be needed to specify allocation of the fenv_t
temporary (whether in memory or registers).
> doesnt exist, we just wont emit it. we could add a warning easily enough in
> this case.
Note there's a difference between no need to emit it, no warning should be
given (soft float) and need to emit it but patterns not yet written so
warning should be given (hard float but patterns not yet implemented for
the architecture).
--
Joseph S. Myers
jos...@codesourcery.com
