On Wed, Aug 13, 2014 at 8:35 PM, Paul E. McKenney
wrote:
>>
>> If the stores to 'b' differ, then there is no issue. Why not document how to
>> avoid re-ordering in the case where both the stores are the same? In that
>> case
>> using a stronger barrier like mb() should be sufficient for both the
On Wed, Aug 13, 2014 at 08:10:22PM -0400, Pranith Kumar wrote:
>
>
> On Wed, Aug 13, 2014 at 6:44 PM, Paul E. McKenney
> wrote:
>
> > .LFB0:
> > .cfi_startproc
> > movla, %ecx
> > movl$1717986919, %edx
> > movl
On Wed, Aug 13, 2014 at 6:44 PM, Paul E. McKenney
wrote:
> .LFB0:
> .cfi_startproc
> movla, %ecx
> movl$1717986919, %edx
> movl%ecx, %eax
> imull %edx
> movl%ecx, %eax
>
On Tue, Aug 05, 2014 at 08:13:54AM -0400, Pranith Kumar wrote:
> On Tue, Aug 5, 2014 at 3:32 AM, Peter Zijlstra wrote:
> >>
> >> 685 This transformation loses the ordering between the load from variable
> >> 'a'
> >> 686 and the store to variable 'b'. If you are relying on this ordering,
> >>
On Tue, Aug 05, 2014 at 08:13:54AM -0400, Pranith Kumar wrote:
On Tue, Aug 5, 2014 at 3:32 AM, Peter Zijlstra pet...@infradead.org wrote:
685 This transformation loses the ordering between the load from variable
'a'
686 and the store to variable 'b'. If you are relying on this ordering,
On Wed, Aug 13, 2014 at 6:44 PM, Paul E. McKenney paul...@linux.vnet.ibm.com
wrote:
.LFB0:
.cfi_startproc
movla, %ecx
movl$1717986919, %edx
movl%ecx, %eax
imull %edx
On Wed, Aug 13, 2014 at 08:10:22PM -0400, Pranith Kumar wrote:
On Wed, Aug 13, 2014 at 6:44 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
.LFB0:
.cfi_startproc
movla, %ecx
movl$1717986919, %edx
On Wed, Aug 13, 2014 at 8:35 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
If the stores to 'b' differ, then there is no issue. Why not document how to
avoid re-ordering in the case where both the stores are the same? In that
case
using a stronger barrier like mb() should be
On Tue, Aug 05, 2014 at 08:13:54AM -0400, Pranith Kumar wrote:
> >> 689 q = ACCESS_ONCE(a);
> >> 690 BUILD_BUG_ON(MAX <= 1); /* Order load from a with store to b.
> >> */
> >> 691 if (q % MAX) {
> >> 692 ACCESS_ONCE(b) = p;
> >> 693
On Tue, Aug 5, 2014 at 3:32 AM, Peter Zijlstra wrote:
>>
>> 685 This transformation loses the ordering between the load from variable 'a'
>> 686 and the store to variable 'b'. If you are relying on this ordering, you
>> 687 should do something like the following:
>> 688
>> 689 q =
On Mon, Aug 04, 2014 at 05:03:00PM -0400, Pranith Kumar wrote:
> On Mon, Aug 4, 2014 at 2:52 PM, Paul E. McKenney
> wrote:
> >>
> >> Given that there is an explicit barrier() in both the branches of
> >> if/else statement, how can the above transformation happen? The
> >> compiler cannot just
On Mon, Aug 04, 2014 at 05:03:00PM -0400, Pranith Kumar wrote:
On Mon, Aug 4, 2014 at 2:52 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
Given that there is an explicit barrier() in both the branches of
if/else statement, how can the above transformation happen? The
compiler
On Tue, Aug 5, 2014 at 3:32 AM, Peter Zijlstra pet...@infradead.org wrote:
685 This transformation loses the ordering between the load from variable 'a'
686 and the store to variable 'b'. If you are relying on this ordering, you
687 should do something like the following:
688
689 q
On Tue, Aug 05, 2014 at 08:13:54AM -0400, Pranith Kumar wrote:
689 q = ACCESS_ONCE(a);
690 BUILD_BUG_ON(MAX = 1); /* Order load from a with store to b.
*/
691 if (q % MAX) {
692 ACCESS_ONCE(b) = p;
693 do_something();
694
On Mon, Aug 4, 2014 at 2:52 PM, Paul E. McKenney
wrote:
>>
>> Given that there is an explicit barrier() in both the branches of
>> if/else statement, how can the above transformation happen? The
>> compiler cannot just remove the barrier(), right?
>
> No, the compiler cannot just remove the
On Mon, Aug 04, 2014 at 01:07:47PM -0400, Pranith Kumar wrote:
> The section "Control Dependencies" in memory-barriers.txt has the
> following text:
>
> 662 In addition, you need to be careful what you do with the local variable
> 'q',
> 663 otherwise the compiler might be able to guess the
The section "Control Dependencies" in memory-barriers.txt has the
following text:
662 In addition, you need to be careful what you do with the local variable 'q',
663 otherwise the compiler might be able to guess the value and again remove
664 the needed conditional. For example:
665
666
The section Control Dependencies in memory-barriers.txt has the
following text:
662 In addition, you need to be careful what you do with the local variable 'q',
663 otherwise the compiler might be able to guess the value and again remove
664 the needed conditional. For example:
665
666 q
On Mon, Aug 04, 2014 at 01:07:47PM -0400, Pranith Kumar wrote:
The section Control Dependencies in memory-barriers.txt has the
following text:
662 In addition, you need to be careful what you do with the local variable
'q',
663 otherwise the compiler might be able to guess the value and
On Mon, Aug 4, 2014 at 2:52 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
Given that there is an explicit barrier() in both the branches of
if/else statement, how can the above transformation happen? The
compiler cannot just remove the barrier(), right?
No, the compiler cannot just
20 matches
Mail list logo
