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: [C11-atomic] [patch] gimple atomic statements


On Wed, Apr 4, 2012 at 3:26 PM, Richard Henderson <rth@redhat.com> wrote:
> On 04/04/2012 04:45 AM, Richard Guenther wrote:
>> I suppose you do not want to use builtins because for primitive types you
>> end up with multiple statements for something "atomic"?
>
> The primary motivation is that builtins cannot return two values.
>
> Our current builtin returns one of the two values by reference, as
> one would do from plain old C. ?Even though we drop the reference
> when we convert from gimple to rtl, this is not good enough to clean
> up the variable we forced to a stack slot.

If that is the only reason you can return two values by using a complex
or vector type (that would be only an IL implementation detail as far
as I can see).
We use that trick to get sincos () "sane" in our IL as well.

Are there other reasons to go with a new GIMPLE code?

> I suggested a specialized GIMPLE_ATOMIC opcode instead of doing a
> totally generalized GIMPLE_ASSIGN_N, returning N values.

We already support multiple SSA defs btw, there is just no operand slot for
it that is properly named or handled by the operand scanner.  Thus, a
new GIMPLE_ASSIGN sub-code class would do, too (of course nobody
expects multiple DEFs here thus it would not be a very good idea to do
that, IMHO).

Richard.

>
> r~


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