This is the mail archive of the 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: [C11-atomic] [patch] gimple atomic statements

On 04/04/2012 10:33 AM, Richard Guenther wrote:
On Wed, Apr 4, 2012 at 3:28 PM, Andrew MacLeod<>  wrote:
This is a WIP... that fntype fields is there for simplicity..   and no...
you can do a 1 byte atomic operation on a full word object if you want by

Oh, so you rather need a size or a mode specified, not a "fntype"?

yes, poorly named perhaps as I created things... its just a type node at the moment that indicates the size being operated on that I collected from the builtin in function.

In the example you only ever use address operands (not memory operands) to the GIMPLE_ATOMIC - is that true in all cases? Is the result always non-memory?
The atomic address can be any arbitrary memory location... I haven't gotten to that yet. its commonly just an address so I'm working with that first as proof of concept. When it gets something else it'll trap and I'll know :-)

Results are always non-memory, other than the side effects of the atomic contents changing and having to up date the second parameter to the compare_exchange routine. The generic routines for arbitary structures (not added in yet), actually just work with blocks of memory, but they are all handled by addresses and the functions themselves are typically void. I was planning on folding them right into the existing atomic_kinds as well... I can recognize from the type that it wont map to a integral type. I needed separate builtins in 4.7 for them since the parameter list was different.
I suppose the GIMPLE_ATOMICs are still optimization barriers for all
memory, not just that possibly referenced by them?

yes, depending on the memory model used. It can force synchronization with other CPUs/threads which will have the appearence of changing any shared memory location. Various guarantees are made about whether those changes are visible to this thread after an atomic operation so we can't reuse shared values in those cases. Various guarantees are made about what changes this thread has made are visible to other CPUs/threads at an atomic call as well, so that precludes moving stores downward in some models.

and during expansion to RTL, can trivially see that cmpxchg.2_4 is not used,
and generate the really efficient compare and swap pattern which only
produces a boolean result.
I suppose gimple stmt folding could transform it as well?
it could if I provided gimple statements for the 3 different forms of C&S. I was planning to just leave it this way since its the interface being forced by C++11 as well as C11... and then just emit the appropriate RTL for this one C&S type. The RTL patterns are already defined for the 2 easy cases for the __sync routines. the third one was added for __atomic. Its possible that the process of integrating the __sync routines with GIMPLE_ATOMIC will indicate its better to add those forms as atomic_kinds and then gimple_fold_stmt could take care of it as well. Maybe that is just a good idea anyway... I'll keep it in mind.

   if only cmpxchg.2_4 were used, we can generate
the C&S pattern which only returns the result.  Only if we see both are
actually used do we have to fall back to the much uglier pattern we have
that produces both results.  Currently we always generate this pattern.

Next, we have the C11 atomic type qualifier which needs to be implemented.
  Every reference to this variable is going to have to be expanded into one
or more atomic operations of some sort.  Yes, I probably could do that by
emitting built-in functions, but they are a bit more unwieldy, its far
simpler to just create gimple_statements.
As I understand you first generate builtins anyway and then lower them?
Or are you planning on emitting those for GENERIC as well?  Remember
GENERIC is not GIMPLE, so you'd need new tree codes anyway ;)
Or do you plan to make __atomic integral part of GENERIC and thus
do this lowering during gimplification?
I was actually thinking about doing it during gimplification... I hadnt gotten as far as figuring out what to do with the functions from the front end yet. I dont know that code well, but I was in fact hoping there was a way to 'recognize' the function names easily and avoid built in functions completely...

The C parser is going to have to understand the set of C11 routine names for all these anyway.. I figured there was something in there that could be done.

I also hope that when done, I can also remove all the ugly built-in overload
code that was created for __sync and continues to be used by __atomic.
But the builtins will stay for our users consumption and libstdc++ use, no?

well, the names must remain exposed and recognizable since they are 'out there'. Maybe under the covers I can just leave them as normal calls and then during gimplification simply recognize the names and generate GIMPLE_ATOMIC statements directly from the CALL_EXPR. That would be ideal. That way there are no builtins any more.

So bottom line, a GIMPLE_ATOMIC statement is just an object that is much
easier to work with.
Yes, I see that it is easier to work with for you.  All other statements will
see GIMPLE_ATOMICs as blockers for their work though, even if they
already deal with calls just fine - that's why I most of the time suggest
to use builtins (or internal fns) to do things (I bet you forgot to update
enough predicates ...).  Can GIMPLE_ATOMICs throw with -fnon-call-exceptions?
I suppose yes.  One thing you missed at least ;)

Not that I am aware of, they are 'noexcept'. But I'm sure I've missed more than a few things so far. Im pretty early in the process :-)

  It cleans up both initial creation and rtl generation,
as well as being easier to manipulate. It also encompasses an entire class
of operations that are becoming more integral *if* we can make them
efficient, and I hope to actually do some optimizations on them eventually.
  I had a discussion last fall with Linus about what we needed to be able to
do to them in order for the kernel to use __atomic instead of their
home-rolled solutions.  Could I do everything with builtins? sure... its
just more awkward and this approach seems cleaner to me.
Cleaner if you look at it in isolation - messy if you consider that not only
things working with atomics need to (not) deal with these new stmt kind.

They can affect shared memory in some ways like a call, but don't have many of the other attributes of call. They are really more like an assignment or other operation with arbitrary shared memory side effects. I do hope to be able to teach the optimizers the directionality of the memory model restrictions. ie, ACQUIRE is only a barrier to hoisting shared memory code... stores can be moved downward past this mode. RELEASE is only a barrier to sinking code. RELAXED is no barrier at all to code motion. In fact, a relaxed store is barely different than a real store... but there is a slight difference so we can't make it a normal store :-P.

By teaching the other parts of the compiler about a GIMPLE_ ATOMIC, we could hopefully lessen their impact eventually.


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