On Mon, 13 Feb 2012, Richard Henderson wrote:
On 02/13/2012 01:35 AM, Richard Guenther wrote:
On Fri, 10 Feb 2012, Richard Henderson wrote:
On 02/10/2012 01:44 AM, Richard Guenther wrote:
What is the reason to keep a GIMPLE_TRANSACTION stmt after
TM lowering and not lower it to a
On Fri, 10 Feb 2012, Richard Henderson wrote:
On 02/10/2012 01:44 AM, Richard Guenther wrote:
What is the reason to keep a GIMPLE_TRANSACTION stmt after
TM lowering and not lower it to a builtin function call?
Because real optimization hasn't happened yet, and we hold
out hope that we'll
On 02/13/2012 01:35 AM, Richard Guenther wrote:
On Fri, 10 Feb 2012, Richard Henderson wrote:
On 02/10/2012 01:44 AM, Richard Guenther wrote:
What is the reason to keep a GIMPLE_TRANSACTION stmt after
TM lowering and not lower it to a builtin function call?
Because real optimization hasn't
On Thu, 9 Feb 2012, Richard Henderson wrote:
From: rguenth at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org
the __transaction_atomic // SUBCODE=[ GTMA_HAVE_STORE ] statement
looks like an overly optimistic way to start a transaction in my quick view.
Indeed. At some point this worked, but
On 02/10/2012 01:44 AM, Richard Guenther wrote:
What is the reason to keep a GIMPLE_TRANSACTION stmt after
TM lowering and not lower it to a builtin function call?
Because real optimization hasn't happened yet, and we hold
out hope that we'll be able to delete stuff as unreachable.
Especially
From: rguenth at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org
the __transaction_atomic // SUBCODE=[ GTMA_HAVE_STORE ] statement
looks like an overly optimistic way to start a transaction in my quick view.
Indeed. At some point this worked, but this may have gotten lost
during one of the merges.
On Thu, 2012-02-09 at 15:05 -0800, Richard Henderson wrote:
+ /* The beginning of a transaction is a memory barrier.
*/
+ /* ??? If we were really cool, we'd only be a barrier
+for the memories touched within the transaction. */
Why? I'm not quite
