On 07/30/2013 09:44 AM, Andrew MacLeod wrote:
On 07/30/2013 09:16 AM, Joseph S. Myers wrot
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 :-)
I worked out the built-ins and what they need to do... and you know
what? I'm not sure I see the point any more.
I am going to give a shot at simply expanding this code right in the
front end. For the floating and complex types I'll create temps and
pass them to the generic atomic routines for load and
compare_exchange... I should be able to directly call the same routines
that sort out what can be mapped to lock free and what can't. And in
the end, the optimizers can sort out how to make things better. that way
we dont need any support anywhere else. (well, we may need 3 builtins
for the floating point stuff.. I don't know.. I'll worry about that later.)
On a side note, after Friday, I'm off for 2 weeks, so I'll be pretty
quiet until the 19th or 20th.
Btw, if anyone wants to take a stab at a stdatomic.h file, that would be
OK with me :-)
Andrew
