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 07/30/2013 09:16 AM, Joseph S. Myers wrot
My reasoning for such a flag is:



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.

I agree.

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).

In fact, the flag could be the presence of the fenv_t variable.. Null for that variable field in the builtin indicate you don't need the patterns emitted.

I';ll get back to you in a bit with the actual built-in's format once I poke around the existing one and see how I can leverage it. I rewrote all that code last year and it ought to be pretty simple to add new operand support. It better be anyway :-)

Amndrew




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