This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add atomic type qualifier


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
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]