[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKKQTT0Z4220G34_PB_iW74UtEsgo3nt3Rbv3nPy0m6Mbwg+9g@mail.gmail.com>
Date: Tue, 18 Feb 2014 15:16:33 +0000
From: Mark Batty <Mark.Batty@...cam.ac.uk>
To: "paulmck@...ux.vnet.ibm.com" <paulmck@...ux.vnet.ibm.com>
Cc: Peter Sewell <Peter.Sewell@...cam.ac.uk>, peterz@...radead.org,
Torvald Riegel <triegel@...hat.com>,
torvalds@...ux-foundation.org, Will Deacon <will.deacon@....com>,
Ramana.Radhakrishnan@....com, dhowells@...hat.com,
linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
akpm@...ux-foundation.org, mingo@...nel.org, gcc@....gnu.org
Subject: Re: [RFC][PATCH 0/5] arch: atomic rework
Hi Paul,
Thanks for the document. I'm looking forward to reading the bits about
dependency chains in Linux.
> One point of confusion for me... Example 4 says "language must allow".
> Shouldn't that be "language is permitted to allow"?
When we say "allow", we mean that the optimised execution should be
allowed by the specification, and Implicitly, the unoptimised
execution should remain allowed too. We want to be concrete about what
the language specification allows, and that's why we say "must". It is
not to disallow the unoptimised execution.
> Seems like an
> implementation is always within its rights to avoid an optimization if
> its implementation prevents it from safely detecting the oppportunity
> for that optimization.
That's right.
- Mark
> Or am I missing something here?
>
> Thanx, Paul
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists