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 Mon, 29 Jul 2013, Andrew MacLeod wrote:

> Ive been poking at this today, and Im wondering what you think of the idea of
> adding a flag to MODIFY_EXPR,
> #define MODIFY_EXPR_IS_COMPOUND(NODE)
> MODIFY_EXPR_CHECK(NODE)->base.asm_written_flag
> 
> and set that in the MODIFY_EXPR node when we create it from the "x op= y" form
> in the front end.   That flag seems to be free for expressions.

My suggestion is that the IR generated by the front end should make it 
completely explicit what may need retrying with a compare-and-exchange, 
rather than relying on non-obvious details to reconstruct the semantics 
required at gimplification time - there are too many transformations 
(folding etc.) that may happen on existing trees and no clear way to be 
confident that you can still identify all the operands accurately after 
such transformations.  That is, an ATOMIC_COMPOUND_MODIFY_EXPR or similar, 
whose operands are: the LHS of the assignment; a temporary variable, "old" 
in C11 footnote 113; the RHS; and the "old op val" expression complete 
with the conversion to the type of the LHS.  Gimplification would then 
(carry out the effects of stabilize_reference on the LHS and save_expr on 
the RHS and) do "old = LHS;" followed by the do-while compare-exchange 
loop.

A flag on the expression could indicate that the floating-point semantics 
are required.  I'd guess back ends would need to provide three insn 
patterns, corresponding to feholdexcept, feclearexcept and feupdateenv, 
that there'd be corresponding built-in functions for these used at 
gimplification time, and that a target hook would give the type used for 
fenv_t by these built-in functions (*not* necessarily the same as the 
fenv_t used by any implementation of the functions in libm).  The target 
should also be able to declare that there's no support for floating-point 
exceptions (e.g. for soft-float) and so floating-point cases don't need 
any special handling.

-- 
Joseph S. Myers
joseph@codesourcery.com


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