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 low
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" opti
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 t
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.
Especiall
On Thu, 9 Feb 2012, Richard Henderson wrote:
> > From: rguenth at gcc dot 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 gott
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
> From: rguenth at gcc dot 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. Now,
# .MEM_8 = VD
