Some names include "sync" and some don't?
Well, I was going to blame Aldy :-) but then I went to look at this, and
thats the same way *all* the other __sync instructions seem to be.
ie:
builtins.c:expand_builtin_lock_test_and_set (enum machine_mode mode,
tree exp,
builtins.c: case BUILT_IN_L
On 06/20/2011 03:53 PM, Andrew MacLeod wrote:
> On 06/20/2011 06:33 PM, Richard Henderson wrote:
> If you want to standardize it with SYNC_ for all cases, I will create all
> the new ones that way.
I do think the name of all the bits related to handling a builtin
function should match the builti
On 06/20/2011 06:33 PM, Richard Henderson wrote:
On 06/20/2011 09:22 AM, Andrew MacLeod wrote:
builtins.c:expand_builtin_lock_test_and_set (enum machine_mode mode, tree exp,
builtins.c:case BUILT_IN_LOCK_TEST_AND_SET_1:
builtins.c:case BUILT_IN_LOCK_TEST_AND_SET_2:
builtins.c:case BU
On 06/20/2011 09:22 AM, Andrew MacLeod wrote:
> builtins.c:expand_builtin_lock_test_and_set (enum machine_mode mode, tree exp,
> builtins.c:case BUILT_IN_LOCK_TEST_AND_SET_1:
> builtins.c:case BUILT_IN_LOCK_TEST_AND_SET_2:
> builtins.c:case BUILT_IN_LOCK_TEST_AND_SET_4:
>
> whereas eve
On 06/17/2011 02:12 PM, Andrew MacLeod wrote:
--- machmode.h (working copy)
*** extern enum machine_mode ptr_mode;
*** 275,278
--- 275,291
/* Target-dependent machine mode initialization - in insn-modes.c. */
extern void init_adjust_machine_modes (void);
+ /* Memory
On 06/17/2011 02:12 PM, Andrew MacLeod wrote:
> Do we apply this to mainline? or cxx-mem-model and then bring it all
> over later when they are all done and "perfected" ?
Let's put it over in cxx-mem-model at least until we settle on
the interface at least.
r~
On 06/17/2011 02:12 PM, Andrew MacLeod wrote:
> --- machmode.h(working copy)
> *** extern enum machine_mode ptr_mode;
> *** 275,278
> --- 275,291
> /* Target-dependent machine mode initialization - in insn-modes.c. */
> extern void init_adjust_machine_modes (void)
On 06/02/2011 02:52 PM, Aldy Hernandez wrote:
Wouldn't it be better to pass the model (as an extra CONST_INT
operand) to the expanders? Targets where atomic instructions always act
as full barriers could just ignore that argument, other could decide what
to do based on the value.
*shrug* I don't
On 06/02/2011 02:52 PM, Aldy Hernandez wrote:
> On 06/02/11 14:25, Jakub Jelinek wrote:
>
>>> +case MEMMODEL_SEQ_CST:
>>> + op = sync_mem_exchange_seq_cst_optab;
>>> + break;
>>> +case MEMMODEL_ACQUIRE:
>>> + op = sync_mem_exchange_acq_optab;
>>> + break;
>>> +case
On 06/02/11 14:25, Jakub Jelinek wrote:
+case MEMMODEL_SEQ_CST:
+ op = sync_mem_exchange_seq_cst_optab;
+ break;
+case MEMMODEL_ACQUIRE:
+ op = sync_mem_exchange_acq_optab;
+ break;
+case MEMMODEL_RELEASE:
+ op = sync_mem_exchange_rel_optab;
+ break;
+
On Thu, Jun 02, 2011 at 02:12:38PM -0500, Aldy Hernandez wrote:
> +/* This function expands a fine grained atomic exchange operation:
> + atomically store VAL in MEM and return the previous value in MEM.
> +
> + MEMMODEL is the memory model variant to use.
> + TARGET is an option place to st
On 05/30/11 15:07, Andrew MacLeod wrote:
Aldy was just too excited about working on memory model I think :-)
I've been looking at this, and I propose we go this way :
http://gcc.gnu.org/wiki/Atomic/GCCMM/CodeGen
Still overly excited, but now with a more thorough plan :).
I'm going to concen
On 05/31/2011 06:38 AM, Jakub Jelinek wrote:
Aldy was just too excited about working on memory model I think :-)
I've been looking at this, and I propose we go this way :
http://gcc.gnu.org/wiki/Atomic/GCCMM/CodeGen
Please feel free to criticize, comment on, or ask for
clarification. I usu
On Mon, May 30, 2011 at 04:07:09PM -0400, Andrew MacLeod wrote:
> On 05/23/2011 07:05 PM, Joseph S. Myers wrote:
> >On Mon, 23 May 2011, Aldy Hernandez wrote:
> >
> >>This is a patch implementing builtins for an atomic exchange with full,
> >>acquire, and release memory barrier semantics. It is si
On 05/23/2011 07:05 PM, Joseph S. Myers wrote:
On Mon, 23 May 2011, Aldy Hernandez wrote:
This is a patch implementing builtins for an atomic exchange with full,
acquire, and release memory barrier semantics. It is similar to
__sync_lock_test_and_set(), but the target does not have the option
On Mon, 23 May 2011, Aldy Hernandez wrote:
> This is a patch implementing builtins for an atomic exchange with full,
> acquire, and release memory barrier semantics. It is similar to
> __sync_lock_test_and_set(), but the target does not have the option of
> implementing a reduced functionality of
16 matches
Mail list logo
