On 03/10/12 08:14, Torvald Riegel wrote:
On Fri, 2012-03-09 at 15:48 -0600, Aldy Hernandez wrote:
Torvald is this what you were thinking of?
Yes, but with an exit in the else branch or something that can cause x
not being read after the condition. I _suppose_ that your original
example would
On Fri, Mar 9, 2012 at 10:48 PM, Aldy Hernandez wrote:
>
>> Note that partial PRE (enabled at -O3) can insert expressions into paths
>> that did _not_ execute the expression. For regular PRE you are right.
>>
>> Richard.
>
>
> I've thought about this some more, and Torvald's comment makes a lot o
On Fri, 2012-03-09 at 15:48 -0600, Aldy Hernandez wrote:
> Torvald is this what you were thinking of?
Yes, but with an exit in the else branch or something that can cause x
not being read after the condition. I _suppose_ that your original
example would be an allowed transformation but just becau
Note that partial PRE (enabled at -O3) can insert expressions into paths
that did _not_ execute the expression. For regular PRE you are right.
Richard.
I've thought about this some more, and Torvald's comment makes a lot of
sense. PRE can make things completely redundant, and a later pass
On 03/07/12 03:18, Richard Guenther wrote:
On Tue, Mar 6, 2012 at 9:56 PM, Torvald Riegel wrote:
On Tue, 2012-03-06 at 21:18 +0100, Richard Guenther wrote:
On Tue, Mar 6, 2012 at 6:55 PM, Aldy Hernandez wrote:
On 02/29/12 03:22, Richard Guenther wrote:
So fixing up individual passes is eas
On Tue, Mar 6, 2012 at 9:56 PM, Torvald Riegel wrote:
> On Tue, 2012-03-06 at 21:18 +0100, Richard Guenther wrote:
>> On Tue, Mar 6, 2012 at 6:55 PM, Aldy Hernandez wrote:
>> > On 02/29/12 03:22, Richard Guenther wrote:
>> >
>> >> So fixing up individual passes is easier - I can only think of PRE
On Tue, 2012-03-06 at 21:18 +0100, Richard Guenther wrote:
> On Tue, Mar 6, 2012 at 6:55 PM, Aldy Hernandez wrote:
> > On 02/29/12 03:22, Richard Guenther wrote:
> >
> >> So fixing up individual passes is easier - I can only think of PRE being
> >> problematic right now, I am not aware that any ot
On Tue, Mar 6, 2012 at 6:55 PM, Aldy Hernandez wrote:
> On 02/29/12 03:22, Richard Guenther wrote:
>
>> So fixing up individual passes is easier - I can only think of PRE being
>> problematic right now, I am not aware that any other pass moves loads
>> or stores. So I'd simply pre-compute the stm
On 02/29/12 03:22, Richard Guenther wrote:
So fixing up individual passes is easier - I can only think of PRE being
problematic right now, I am not aware that any other pass moves loads
or stores. So I'd simply pre-compute the stmt bit in PRE and adjust
the
if (gimple_has_volatile_o
On Tue, Feb 28, 2012 at 9:11 PM, Aldy Hernandez wrote:
> On 02/28/12 13:12, Richard Henderson wrote:
>>
>> On 02/28/12 09:44, Aldy Hernandez wrote:
>>>
>>> PR middle-end/51752
>>> * gimple.h (gimple_in_transaction): New.
>>> (gimple_set_in_transaction): New.
>>> (struct
On 02/28/12 13:12, Richard Henderson wrote:
On 02/28/12 09:44, Aldy Hernandez wrote:
PR middle-end/51752
* gimple.h (gimple_in_transaction): New.
(gimple_set_in_transaction): New.
(struct gimple_statement_base): Add in_transaction field.
* tree-ssa-loop-im
On 02/28/12 09:44, Aldy Hernandez wrote:
> PR middle-end/51752
> * gimple.h (gimple_in_transaction): New.
> (gimple_set_in_transaction): New.
> (struct gimple_statement_base): Add in_transaction field.
> * tree-ssa-loop-im.c: (movement_possibility): Restrict movement o
On 02/28/12 11:05, Richard Henderson wrote:
On 02/27/12 08:22, Aldy Hernandez wrote:
transform by making transaction load/store stmts behave the same as
potentially trapping stmts (thus, only optimize if the memory is accessed
unconditional somewhere else). That would work for PRE as well.
[eas
On 02/27/12 08:22, Aldy Hernandez wrote:
>> transform by making transaction load/store stmts behave the same as
>> potentially trapping stmts (thus, only optimize if the memory is accessed
>> unconditional somewhere else). That would work for PRE as well.
>> [easiest would be to make *_could_trap_
On 02/28/2012 04:39 AM, Richard Guenther wrote:
On Mon, Feb 27, 2012 at 5:44 PM, Andrew MacLeod wrote:
I t would seem appropriate to me that in the future, perhaps the CFG could
have a flag set for any basic block which is in a transaction... This would
make it pretty trivial at all times to te
On Mon, Feb 27, 2012 at 5:44 PM, Andrew MacLeod wrote:
> On 02/27/2012 11:22 AM, Aldy Hernandez wrote:
>>
>>
>>> Ok. I see. So, I think what would be best is to have a way to check
>>> whether
>>> a store/load is part of a transaction - do we have a way to do that right
>>> now?
>>> (For example
On Mon, Feb 27, 2012 at 6:29 PM, Aldy Hernandez wrote:
> On 02/27/12 11:02, Michael Matz wrote:
>>
>> Hi,
>>
>> On Mon, 27 Feb 2012, Aldy Hernandez wrote:
>>
>>>
> For that matter, didn't rth add a memory barrier at the beginning of
> transactions last week? That would mean that we can't
On 02/27/12 11:02, Michael Matz wrote:
Hi,
On Mon, 27 Feb 2012, Aldy Hernandez wrote:
For that matter, didn't rth add a memory barrier at the beginning of
transactions last week? That would mean that we can't hoist anything
outside of a transaction anyhow. Or was it not a full memory barri
Hi,
On Mon, 27 Feb 2012, Aldy Hernandez wrote:
>
> > > For that matter, didn't rth add a memory barrier at the beginning of
> > > transactions last week? That would mean that we can't hoist anything
> > > outside of a transaction anyhow. Or was it not a full memory barrier?
> >
> > It's now a
On 02/27/2012 11:22 AM, Aldy Hernandez wrote:
Ok. I see. So, I think what would be best is to have a way to check
whether
a store/load is part of a transaction - do we have a way to do that
right now?
(For example a flag on a gimple stmt?) Then we can simply avoid the LIM
We do not (*).
For that matter, didn't rth add a memory barrier at the beginning of
transactions last week? That would mean that we can't hoist anything
outside of a transaction anyhow. Or was it not a full memory barrier?
It's now a full memory barrier for all global memory and for local statics
if their
Ok. I see. So, I think what would be best is to have a way to check whether
a store/load is part of a transaction - do we have a way to do that right now?
(For example a flag on a gimple stmt?) Then we can simply avoid the LIM
We do not (*). My patch accumulates that information on demand.
Again, __transactions being barriers and all, I don't think we should
complicate things unnecessarily at this point, since it doesn't happen.
Yes. Based on Richard Guenther's examples, my question was whether your
code (without having actually looked at it ;) ) would also allow
post-dominatin
On Mon, Feb 27, 2012 at 10:24 AM, Torvald Riegel wrote:
> On Fri, 2012-02-24 at 10:34 -0600, Aldy Hernandez wrote:
>> On 02/24/12 07:10, Torvald Riegel wrote:
>> > safety. I didn't have time to look at Aldy's patch yet, but a first
>> > safe and conservative way would be to treat transactions as
On Fri, 2012-02-24 at 10:34 -0600, Aldy Hernandez wrote:
> On 02/24/12 07:10, Torvald Riegel wrote:
> > safety. I didn't have time to look at Aldy's patch yet, but a first
> > safe and conservative way would be to treat transactions as full
> > transformation barriers, and prevent publication-safe
On Fri, Feb 24, 2012 at 5:34 PM, Aldy Hernandez wrote:
> On 02/24/12 07:10, Torvald Riegel wrote:
>>
>> On Fri, 2012-02-24 at 09:58 +0100, Richard Guenther wrote:
>>>
>>> On Thu, Feb 23, 2012 at 10:11 PM, Aldy Hernandez
>>> wrote:
On 02/23/12 12:19, Aldy Hernandez wrote:
> abou
On Fri, Feb 24, 2012 at 2:10 PM, Torvald Riegel wrote:
> On Fri, 2012-02-24 at 09:58 +0100, Richard Guenther wrote:
>> On Thu, Feb 23, 2012 at 10:11 PM, Aldy Hernandez wrote:
>> > On 02/23/12 12:19, Aldy Hernandez wrote:
>> >
>> >> about hit me. Instead now I save all loads in a function and iter
On 02/24/12 07:10, Torvald Riegel wrote:
On Fri, 2012-02-24 at 09:58 +0100, Richard Guenther wrote:
On Thu, Feb 23, 2012 at 10:11 PM, Aldy Hernandez wrote:
On 02/23/12 12:19, Aldy Hernandez wrote:
about hit me. Instead now I save all loads in a function and iterate
through them in a brute fo
On Fri, 2012-02-24 at 09:58 +0100, Richard Guenther wrote:
> On Thu, Feb 23, 2012 at 10:11 PM, Aldy Hernandez wrote:
> > On 02/23/12 12:19, Aldy Hernandez wrote:
> >
> >> about hit me. Instead now I save all loads in a function and iterate
> >> through them in a brute force way. I'd like to rewrit
On Thu, Feb 23, 2012 at 10:11 PM, Aldy Hernandez wrote:
> On 02/23/12 12:19, Aldy Hernandez wrote:
>
>> about hit me. Instead now I save all loads in a function and iterate
>> through them in a brute force way. I'd like to rewrite this into a hash
>> of some sort, but before I go any further I'm i
On 02/23/12 12:19, Aldy Hernandez wrote:
about hit me. Instead now I save all loads in a function and iterate
through them in a brute force way. I'd like to rewrite this into a hash
of some sort, but before I go any further I'm interested to know if the
main idea is ok.
For the record, it may
In this PR we have a publication safety violation in a transaction. The
loop invariant motion pass hoists a load out of a loop, creating a load
data race. Those unfamiliar with load data races in transactions,
please see the PR, as this has been confusing to most (me included).
In the snippe
32 matches
Mail list logo
