On Wed, Sep 23, 2015 at 03:30:34PM -0700, Hans Boehm wrote:
> I'd really like this to converge. It's great that it tries to focus on a
> couple of alternatives. But I'm not sure they're the right ones.
>
> I kind of like the 7.9 approach of restricting dependency chain to those
> case in which n
On Mon, Jul 13, 2015 at 05:44:59PM -0700, Paul E. McKenney wrote:
> On Tue, May 19, 2015 at 05:55:10PM -0700, Paul E. McKenney wrote:
> > Hello!
> >
> > Following up on last year's discussion (https://lwn.net/Articles/586838/,
> > https://lwn.net/Articles/588300/), I believe that we have a solutio
On Tue, May 19, 2015 at 05:55:10PM -0700, Paul E. McKenney wrote:
> Hello!
>
> Following up on last year's discussion (https://lwn.net/Articles/586838/,
> https://lwn.net/Articles/588300/), I believe that we have a solution. If
> I am wrong, I am sure you all will let me know, and in great detail
On Tue, May 26, 2015 at 07:08:35PM +0200, Torvald Riegel wrote:
> On Tue, 2015-05-19 at 17:55 -0700, Paul E. McKenney wrote:
> > http://www.rdrop.com/users/paulmck/RCU/consume.2015.05.18a.pdf
>
> I have been discussing Section 7.9 with Paul during last week.
>
> While I think that 7.9 helps
On Thu, 2015-05-21 at 13:42 -0700, Linus Torvalds wrote:
> On Thu, May 21, 2015 at 1:02 PM, Paul E. McKenney
> wrote:
> >
> > The compiler can (and does) speculate non-atomic non-volatile writes
> > in some cases, but I do not believe that it is permitted to speculate
> > either volatile or atomic
On Fri, May 22, 2015 at 06:30:29PM +0100, Will Deacon wrote:
> Hi Paul,
>
> On Thu, May 21, 2015 at 09:02:12PM +0100, Paul E. McKenney wrote:
> > On Thu, May 21, 2015 at 08:24:22PM +0100, Will Deacon wrote:
> > > On Wed, May 20, 2015 at 07:16:06PM +0100, Paul E. McKenney wrote:
> > > > On to #5:
>
Hi Paul,
On Thu, May 21, 2015 at 09:02:12PM +0100, Paul E. McKenney wrote:
> On Thu, May 21, 2015 at 08:24:22PM +0100, Will Deacon wrote:
> > On Wed, May 20, 2015 at 07:16:06PM +0100, Paul E. McKenney wrote:
> > > On to #5:
> > >
> > > r1 = atomic_load_explicit(&x, memory_order_consume);
> > >
On Fri, May 22, 2015 at 08:43:44AM +0200, Ingo Molnar wrote:
>
> * Linus Torvalds wrote:
>
> > (a) the "official" rules are completely pointless, and make sense
> > only because the standard is written for some random "abstract
> > machine" that doesn't actually exist.
>
> Presuming the inte
On Fri, May 22, 2015 at 06:43:32AM -0400, Richard Kenner wrote:
> > (Assuming it's a goal of this standard to be human parseable to more
> > than a few dozen people on the planet.)
>
> Unfortunately, that's rarely a goal of most standards. ;-)
My experience does match Richard's, sad to say. The
> (Assuming it's a goal of this standard to be human parseable to more
> than a few dozen people on the planet.)
Unfortunately, that's rarely a goal of most standards. ;-)
* Linus Torvalds wrote:
> (a) the "official" rules are completely pointless, and make sense
> only because the standard is written for some random "abstract
> machine" that doesn't actually exist.
Presuming the intent of the abstract machine specification is to avoid
being seen as biased to
On Thu, May 21, 2015 at 01:42:11PM -0700, Linus Torvalds wrote:
> On Thu, May 21, 2015 at 1:02 PM, Paul E. McKenney
> wrote:
> >
> > The compiler can (and does) speculate non-atomic non-volatile writes
> > in some cases, but I do not believe that it is permitted to speculate
> > either volatile or
On Thu, May 21, 2015 at 1:02 PM, Paul E. McKenney
wrote:
>
> The compiler can (and does) speculate non-atomic non-volatile writes
> in some cases, but I do not believe that it is permitted to speculate
> either volatile or atomic writes.
I do *not* believe that a compiler is ever allowed to specu
On Thu, May 21, 2015 at 08:24:22PM +0100, Will Deacon wrote:
> On Wed, May 20, 2015 at 07:16:06PM +0100, Paul E. McKenney wrote:
> > On Wed, May 20, 2015 at 04:46:17PM +0100, Will Deacon wrote:
> > > On Wed, May 20, 2015 at 01:15:22PM +0100, Paul E. McKenney wrote:
> > > > Indeed, something like th
On Wed, May 20, 2015 at 07:16:06PM +0100, Paul E. McKenney wrote:
> On Wed, May 20, 2015 at 04:46:17PM +0100, Will Deacon wrote:
> > On Wed, May 20, 2015 at 01:15:22PM +0100, Paul E. McKenney wrote:
> > > Indeed, something like this does -not- carry a dependency from the
> > > memory_order_consume
On Thu, May 21, 2015 at 06:17:43PM +0200, Michael Matz wrote:
> Hi,
>
> On Thu, 21 May 2015, Paul E. McKenney wrote:
>
> > The point is -exactly- to codify the current state of affairs.
>
> Ah, I see, so it's not yet about creating a more useful (for compilers,
> that is) model.
There are seve
Hi,
On Thu, 21 May 2015, Paul E. McKenney wrote:
> The point is -exactly- to codify the current state of affairs.
Ah, I see, so it's not yet about creating a more useful (for compilers,
that is) model.
> > char * fancy_assign (char *in) { return in; }
> > ...
> > char *x, *y;
> >
> >
On Thu, May 21, 2015 at 04:22:38PM +0200, Michael Matz wrote:
> Hi,
>
> On Wed, 20 May 2015, Paul E. McKenney wrote:
>
> > > > I'm not sure... you'd require the compiler to perform static analysis of
> > > > loops to determine the state of the machine when they exit (if they
> > > > exit!)
> > >
Hi,
On Wed, 20 May 2015, Paul E. McKenney wrote:
> > > I'm not sure... you'd require the compiler to perform static analysis of
> > > loops to determine the state of the machine when they exit (if they exit!)
> > > in order to show whether or not a dependency is carried to subsequent
> > > operat
On Wed, May 20, 2015 at 04:54:51PM +0100, Andrew Haley wrote:
> On 05/20/2015 04:46 PM, Will Deacon wrote:
> > I'm not sure... you'd require the compiler to perform static analysis of
> > loops to determine the state of the machine when they exit (if they exit!)
> > in order to show whether or not
On Wed, May 20, 2015 at 04:46:17PM +0100, Will Deacon wrote:
> On Wed, May 20, 2015 at 01:15:22PM +0100, Paul E. McKenney wrote:
> > On Wed, May 20, 2015 at 12:47:45PM +0100, Will Deacon wrote:
> > > On Wed, May 20, 2015 at 03:41:48AM +0100, Paul E. McKenney wrote:
> > > > If a pointer is p
On 05/20/2015 04:46 PM, Will Deacon wrote:
> I'm not sure... you'd require the compiler to perform static analysis of
> loops to determine the state of the machine when they exit (if they exit!)
> in order to show whether or not a dependency is carried to subsequent
> operations. If it can't prove
On Wed, May 20, 2015 at 01:15:22PM +0100, Paul E. McKenney wrote:
> On Wed, May 20, 2015 at 12:47:45PM +0100, Will Deacon wrote:
> > On Wed, May 20, 2015 at 03:41:48AM +0100, Paul E. McKenney wrote:
> > > If a pointer is part of a dependency chain, and if the values
> > > added to or subtracted
Paul E. McKenney wrote:
> Ah, I was assuming between x and z. David, what was your intent? ;-)
Clarification.
David
On Wed, May 20, 2015 at 03:15:48PM +0100, Ramana Radhakrishnan wrote:
>
>
> On 20/05/15 15:03, Paul E. McKenney wrote:
> >On Wed, May 20, 2015 at 02:44:30PM +0100, Ramana Radhakrishnan wrote:
> >>
> >>
> >>On 20/05/15 14:37, David Howells wrote:
> >>>Paul E. McKenney wrote:
> >>>
> I was thi
On 20/05/15 15:03, Paul E. McKenney wrote:
On Wed, May 20, 2015 at 02:44:30PM +0100, Ramana Radhakrishnan wrote:
On 20/05/15 14:37, David Howells wrote:
Paul E. McKenney wrote:
I was thinking of "y" as a simple variable, but if it is something more
complex, then the compiler could do thi
On Wed, May 20, 2015 at 02:44:30PM +0100, Ramana Radhakrishnan wrote:
>
>
> On 20/05/15 14:37, David Howells wrote:
> >Paul E. McKenney wrote:
> >
> >>I was thinking of "y" as a simple variable, but if it is something more
> >>complex, then the compiler could do this, right?
> >>
> >>char *x
On Wed, May 20, 2015 at 02:37:05PM +0100, David Howells wrote:
> Paul E. McKenney wrote:
>
> > I was thinking of "y" as a simple variable, but if it is something more
> > complex, then the compiler could do this, right?
> >
> > char *x;
> >
> > y;
> > x = z;
>
> Yeah. I presume it
On 20/05/15 14:37, David Howells wrote:
Paul E. McKenney wrote:
I was thinking of "y" as a simple variable, but if it is something more
complex, then the compiler could do this, right?
char *x;
y;
x = z;
Yeah. I presume it has to maintain the ordering, though.
Paul E. McKenney wrote:
> I was thinking of "y" as a simple variable, but if it is something more
> complex, then the compiler could do this, right?
>
> char *x;
>
> y;
> x = z;
Yeah. I presume it has to maintain the ordering, though.
David
On Wed, May 20, 2015 at 02:18:37PM +0100, David Howells wrote:
> Paul E. McKenney wrote:
>
> > > Additionally, what about the following code?
> > >
> > > char *x = y ? z : z;
> > >
> > > Does that extend a dependency chain from z to x? If so, I can imagine a
> > > CPU breaking that in practic
Paul E. McKenney wrote:
> > Additionally, what about the following code?
> >
> > char *x = y ? z : z;
> >
> > Does that extend a dependency chain from z to x? If so, I can imagine a
> > CPU breaking that in practice.
>
> I am not seeing this. I would expect the compiler to optimize to
> som
On Wed, May 20, 2015 at 12:47:45PM +0100, Will Deacon wrote:
> Hi Paul,
>
> On Wed, May 20, 2015 at 03:41:48AM +0100, Paul E. McKenney wrote:
> > On Tue, May 19, 2015 at 07:10:12PM -0700, Linus Torvalds wrote:
> > > On Tue, May 19, 2015 at 6:57 PM, Linus Torvalds
> > > wrote:
> > > So I think you
On Wed, May 20, 2015 at 11:03:00AM +0200, Richard Biener wrote:
> On Wed, May 20, 2015 at 9:34 AM, Jens Maurer wrote:
> > On 05/20/2015 04:34 AM, Paul E. McKenney wrote:
> >> On Tue, May 19, 2015 at 06:57:02PM -0700, Linus Torvalds wrote:
> >
> >>> - the "you can add/subtract integral values" sti
On Wed, May 20, 2015 at 09:34:10AM +0200, Jens Maurer wrote:
> On 05/20/2015 04:34 AM, Paul E. McKenney wrote:
> > On Tue, May 19, 2015 at 06:57:02PM -0700, Linus Torvalds wrote:
>
> >> - the "you can add/subtract integral values" still opens you up to
> >> language lawyers claiming "(char *)ptr
Hi Paul,
On Wed, May 20, 2015 at 03:41:48AM +0100, Paul E. McKenney wrote:
> On Tue, May 19, 2015 at 07:10:12PM -0700, Linus Torvalds wrote:
> > On Tue, May 19, 2015 at 6:57 PM, Linus Torvalds
> > wrote:
> > So I think you're better off just saying that operations designed to
> > drop significant
On Wed, May 20, 2015 at 9:34 AM, Jens Maurer wrote:
> On 05/20/2015 04:34 AM, Paul E. McKenney wrote:
>> On Tue, May 19, 2015 at 06:57:02PM -0700, Linus Torvalds wrote:
>
>>> - the "you can add/subtract integral values" still opens you up to
>>> language lawyers claiming "(char *)ptr - (intptr_t)
On 05/20/2015 04:34 AM, Paul E. McKenney wrote:
> On Tue, May 19, 2015 at 06:57:02PM -0700, Linus Torvalds wrote:
>> - the "you can add/subtract integral values" still opens you up to
>> language lawyers claiming "(char *)ptr - (intptr_t)ptr" preserving the
>> dependency, which it clearly doesn't
On Tue, May 19, 2015 at 07:10:12PM -0700, Linus Torvalds wrote:
> On Tue, May 19, 2015 at 6:57 PM, Linus Torvalds
> wrote:
> >
> > - the "you can add/subtract integral values" still opens you up to
> > language lawyers claiming "(char *)ptr - (intptr_t)ptr" preserving the
> > dependency, which it
On Tue, May 19, 2015 at 06:57:02PM -0700, Linus Torvalds wrote:
> On Tue, May 19, 2015 at 5:55 PM, Paul E. McKenney
> wrote:
> >
> > http://www.rdrop.com/users/paulmck/RCU/consume.2015.05.18a.pdf
>
> >From a very quick read-through, the restricted dependency chain in 7.9
> seems to be rea
On Tue, May 19, 2015 at 6:57 PM, Linus Torvalds
wrote:
>
> - the "you can add/subtract integral values" still opens you up to
> language lawyers claiming "(char *)ptr - (intptr_t)ptr" preserving the
> dependency, which it clearly doesn't. But language-lawyering it does,
> since all those operatio
On Tue, May 19, 2015 at 5:55 PM, Paul E. McKenney
wrote:
>
> http://www.rdrop.com/users/paulmck/RCU/consume.2015.05.18a.pdf
>From a very quick read-through, the restricted dependency chain in 7.9
seems to be reasonable, and essentially covers "thats' what hardware
gives us anyway", making
42 matches
Mail list logo
