From: Andrew MacLeod <amacleod@redhat.com>
To: "Joseph S. Myers" <joseph@codesourcery.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>,
Richard Henderson <rth@redhat.com>
Subject: Re: [PATCH] Add atomic type qualifier
Date: Wed, 31 Jul 2013 12:19:00 -0000 [thread overview]
Message-ID: <51F8FD42.7020504@redhat.com> (raw)
In-Reply-To: <51F7C329.305@redhat.com>
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
next prev parent reply other threads:[~2013-07-31 12:04 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-26 17:18 Andrew MacLeod
2013-07-26 19:24 ` Andi Kleen
2013-07-26 19:34 ` Andrew MacLeod
2013-07-26 21:14 ` Andi Kleen
2013-07-26 22:29 ` Andrew MacLeod
2013-07-26 20:42 ` Hans-Peter Nilsson
2013-07-26 23:58 ` Joseph S. Myers
2013-07-27 1:15 ` Andrew MacLeod
2013-08-01 21:54 ` Andrew MacLeod
2013-07-28 21:15 ` Joseph S. Myers
2013-07-29 15:47 ` Andrew MacLeod
2013-07-29 16:12 ` Joseph S. Myers
2013-07-29 16:30 ` Andrew MacLeod
2013-07-29 16:48 ` Joseph S. Myers
2013-07-29 18:20 ` Andrew MacLeod
2013-07-29 23:24 ` Andrew MacLeod
2013-07-30 12:03 ` Joseph S. Myers
2013-07-30 12:38 ` Andrew MacLeod
2013-07-30 13:25 ` Joseph S. Myers
2013-07-30 13:58 ` Andrew MacLeod
2013-07-31 12:19 ` Andrew MacLeod [this message]
2013-07-29 16:24 ` Andrew MacLeod
2013-07-30 16:56 ` [PATCH 0/5] Atomic " Andrew MacLeod
2013-07-30 17:13 ` [PATCH 2/5] Atomic type qualifier - Add atomic type to tree node Andrew MacLeod
2013-07-30 17:14 ` [PATCH 1/5] Atomic type qualifier - Add type alignment override hook Andrew MacLeod
2013-07-30 17:14 ` [PATCH 3/5] Atomic type qualifier - front end changes Andrew MacLeod
2013-08-09 0:06 ` Joseph S. Myers
2013-07-30 17:14 ` [PATCH 4/5] Atomic type qualifier - Change built-in function types Andrew MacLeod
2013-07-30 17:32 ` [PATCH 5/5] Atomic type qualifier - Use atomic objects Andrew MacLeod
2013-08-02 19:22 ` [PATCH] - C11 expressions and stdatomic.h - Just for current state Andrew MacLeod
2013-08-07 23:06 ` Joseph S. Myers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51F8FD42.7020504@redhat.com \
--to=amacleod@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=joseph@codesourcery.com \
--cc=rth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).