On 11/28/2011 06:01 AM, David Gilbert wrote:
> Hi Rchard,
> Can you explain the code:
>
> + if (mod_f != MEMMODEL_RELAXED)
> +emit_label (label2);
> +
> + arm_post_atomic_barrier (mod_s);
> +
> + if (mod_f == MEMMODEL_RELAXED)
> +emit_label (label2);
> +}
>
> in the case of the exist
On 23 November 2011 23:43, Richard Henderson wrote:
> This transformation is quite a bit more dramatic than the other ports because
> ARM was not splitting the code sequences post-reload. Indeed, the failure to
> split resulted in a distinctly odd coding style where fake output routines
> were
On 11/24/2011 02:51 AM, Marcus Shawcroft wrote:
> Would the addition of blockages around each load exclusive and store
> exclusive be sufficient to guarantee no load or store was scheduled
> between the exclusives?
The ldrex/strex insns themselves are written as barriers,
and yes, that is sufficie
On 11/24/2011 01:55 AM, Richard Earnshaw wrote:
> That was deliberate. The ARM ARM says that it is unsafe to have any
> other load or store instruction between an LDREX and its matching STREX.
> If we split these instructions before the final scheduling operation
> then there is a chance of that
On 23/11/11 23:43, Richard Henderson wrote:
+/* Split a compare and swap pattern. It is IMPLEMENTATION DEFINED whether
+ another memory store between the load-exclusive and store-exclusive can
+ reset the monitor from Exclusive to Open state. This means we must wait
+ until after reload t
On 23/11/11 23:43, Richard Henderson wrote:
> This transformation is quite a bit more dramatic than the other ports
> because ARM was not splitting the code sequences post-reload.
> Indeed, the failure to split resulted in a distinctly odd coding
> style where fake output routines were used to comp
