On 29/05/15 20:40, Jason Merrill wrote:
On 05/29/2015 09:18 AM, Ramana Radhakrishnan wrote:
+static tree
+build_atomic_load_byte (tree src, HOST_WIDE_INT model)
This function needs a comment. The C++ changes are OK with that.
Jason
I'm assuming your review and rth's review constitute an
On Fri, May 29, 2015 at 9:18 AM, Ramana Radhakrishnan
wrote:
> - Turns build_atomic_load into build_atomic_load_byte in order
> to do an atomic load of 1 byte instead of a full word atomic load.
> - Restructures get_guard_cond to decide whether to use an atomic load
> or a standard load depen
On 05/29/2015 09:18 AM, Ramana Radhakrishnan wrote:
+static tree
+build_atomic_load_byte (tree src, HOST_WIDE_INT model)
This function needs a comment. The C++ changes are OK with that.
Jason
On 05/29/2015 06:18 AM, Ramana Radhakrishnan wrote:
>
> One of the bits of fallout that I've observed in my testing and that I'm not
> sure about what to do is that on *bare-metal* arm-none-eabi targets we still
> put out calls to __sync_synchronize on architecture versions that do not have
> a
>
On 05/29/2015 06:18 AM, Ramana Radhakrishnan wrote:
>
> PR c++/66192
> * config/alpha/alpha.c (TARGET_RELAXED_ORDERING): Likewise.
> * config/ia64/ia64.c (TARGET_RELAXED_ORDERING): Likewise.
> * config/rs6000/rs6000.c (TARGET_RELAXED_ORDERING): Likewise.
> * config/sparc/linux.
On 22/05/15 18:36, Jason Merrill wrote:
On 05/22/2015 11:23 AM, Ramana Radhakrishnan wrote:
On 22/05/15 15:28, Jason Merrill wrote:
I do notice that get_guard_bits after build_atomic_load just won't work
on non-ARM targets, as it ends up trying to take the address of a value.
So on powerpc
Hello!
> This patch removes the special casing for targets with relaxed memory
> ordering and handles
> guard accesses with equivalent atomic load acquire operations. In this
> process we change the
> algorithm to load the guard variable with an atomic load that has ACQUIRE
> semantics. I'm not
On 05/22/2015 10:36 AM, Jason Merrill wrote:
> It also seems unnecessary to load 8 bytes on any target; we could add a
> function to optabs.c that returns the smallest mode for which there's atomic
> load support?
No, while we do use an atomic_load pattern if it exists, we assume that
all loads no
On 05/22/2015 11:23 AM, Ramana Radhakrishnan wrote:
On 22/05/15 15:28, Jason Merrill wrote:
I do notice that get_guard_bits after build_atomic_load just won't work
on non-ARM targets, as it ends up trying to take the address of a value.
So on powerpc where targetm.guard_mask_bit is false - thi
On Fri, May 22, 2015 at 11:23 AM, Ramana Radhakrishnan
wrote:
> So on powerpc where targetm.guard_mask_bit is false - this is what I see.
>
>
> {
> static int * p;
>
> static int * p;
> if (< __atomic_load_8 (&_ZGVZ1fvE1p, 2) == 0>>)
> {
> if (<>)
> {
> < TAR
On 22/05/15 15:28, Jason Merrill wrote:
On 05/22/2015 09:55 AM, David Edelsohn wrote:
On Fri, May 22, 2015 at 9:40 AM, Jason Merrill wrote:
On 05/22/2015 07:23 AM, Ramana Radhakrishnan wrote:
+ /* Load the guard value only through an atomic acquire load. */
+ guard = build_atomic_load (
On 05/22/2015 09:55 AM, David Edelsohn wrote:
On Fri, May 22, 2015 at 9:40 AM, Jason Merrill wrote:
On 05/22/2015 07:23 AM, Ramana Radhakrishnan wrote:
+ /* Load the guard value only through an atomic acquire load. */
+ guard = build_atomic_load (guard, MEMMODEL_ACQUIRE);
+
/* Check t
On 22/05/15 14:40, Jason Merrill wrote:
On 05/22/2015 07:23 AM, Ramana Radhakrishnan wrote:
+ /* Load the guard value only through an atomic acquire load. */
+ guard = build_atomic_load (guard, MEMMODEL_ACQUIRE);
+
/* Check to see if the GUARD is zero. */
guard = get_guard_bits (gu
On Fri, May 22, 2015 at 9:40 AM, Jason Merrill wrote:
> On 05/22/2015 07:23 AM, Ramana Radhakrishnan wrote:
>>
>> + /* Load the guard value only through an atomic acquire load. */
>> + guard = build_atomic_load (guard, MEMMODEL_ACQUIRE);
>> +
>> /* Check to see if the GUARD is zero. */
>>
On 05/22/2015 07:23 AM, Ramana Radhakrishnan wrote:
+ /* Load the guard value only through an atomic acquire load. */
+ guard = build_atomic_load (guard, MEMMODEL_ACQUIRE);
+
/* Check to see if the GUARD is zero. */
guard = get_guard_bits (guard);
I wonder if these calls should be r
Bah ! now with patch attached.
Ramana
diff --git a/gcc/config/alpha/alpha.c b/gcc/config/alpha/alpha.c
index 1ba99d0..857c9ac 100644
--- a/gcc/config/alpha/alpha.c
+++ b/gcc/config/alpha/alpha.c
@@ -9987,12 +9987,6 @@ alpha_atomic_assign_expand_fenv (tree *hold, tree
*clear, tree *update)
#unde
All,
This patch removes the special casing for targets with relaxed memory
ordering and handles guard accesses with equivalent atomic load acquire
operations. In this process we change the algorithm to load the guard
variable with an atomic load that has ACQUIRE semantics. I'm not
terribly
17 matches
Mail list logo
