On Thu, 8 Feb 2001, Stephen Wille Padnos wrote:
> "Richard B. Johnson" wrote:
> >
> > On Thu, 8 Feb 2001, Stephen Wille Padnos wrote:
> >
> > > "Richard B. Johnson" wrote:
> > > [snip]
> > > > Another problem with 'volatile' has to do with pointers. When
> > > > it's possible for some object
"Richard B. Johnson" wrote:
>
> On Thu, 8 Feb 2001, Stephen Wille Padnos wrote:
>
> > "Richard B. Johnson" wrote:
> > [snip]
> > > Another problem with 'volatile' has to do with pointers. When
> > > it's possible for some object to be modified by some external
> > > influence, we see:
> > >
> >
On Thu, 8 Feb 2001, Stephen Wille Padnos wrote:
> "Richard B. Johnson" wrote:
> [snip]
> > Another problem with 'volatile' has to do with pointers. When
> > it's possible for some object to be modified by some external
> > influence, we see:
> >
> > volatile struct whatever *ptr;
> >
>
"Richard B. Johnson" wrote:
[snip]
> Another problem with 'volatile' has to do with pointers. When
> it's possible for some object to be modified by some external
> influence, we see:
>
> volatile struct whatever *ptr;
>
> Now, it's unclear if gcc knows that we don't give a damn about
>
On Thu, 8 Feb 2001, Hugh Dickins wrote:
> On Wed, 7 Feb 2001, Linus Torvalds wrote:
> > On Wed, 7 Feb 2001, Hugh Dickins wrote:
> > >
> > > None of those optimizes this: I believe the semantics of "||" (don't
> > > try next test if first succeeds) forbid the optimization "|" gives?
> >
> > No.
On Thu, 8 Feb 2001, Hugh Dickins wrote:
> On Thu, 8 Feb 2001, David Weinehall wrote:
> >
> > Well, after all, it's debugging code, and the code now is easy to read.
> > Your code, while more efficient, isn't. I think that clarity takes
> > priority over efficiency in non-critical code such as
On Thu, 8 Feb 2001, David Weinehall wrote:
>
> Well, after all, it's debugging code, and the code now is easy to read.
> Your code, while more efficient, isn't. I think that clarity takes
> priority over efficiency in non-critical code such as debugging
> code. Of course, this is my personal
On Thu, Feb 08, 2001 at 04:24:23PM +, Hugh Dickins wrote:
> On Wed, 7 Feb 2001, Linus Torvalds wrote:
> > On Wed, 7 Feb 2001, Hugh Dickins wrote:
> > >
> > > None of those optimizes this: I believe the semantics of "||" (don't
> > > try next test if first succeeds) forbid the optimization
On Wed, 7 Feb 2001, Linus Torvalds wrote:
> On Wed, 7 Feb 2001, Hugh Dickins wrote:
> >
> > None of those optimizes this: I believe the semantics of "||" (don't
> > try next test if first succeeds) forbid the optimization "|" gives?
>
> No. The optimization is entirely legal - but the fact that
On Wed, 7 Feb 2001, Linus Torvalds wrote:
On Wed, 7 Feb 2001, Hugh Dickins wrote:
None of those optimizes this: I believe the semantics of "||" (don't
try next test if first succeeds) forbid the optimization "|" gives?
No. The optimization is entirely legal - but the fact that
On Thu, Feb 08, 2001 at 04:24:23PM +, Hugh Dickins wrote:
On Wed, 7 Feb 2001, Linus Torvalds wrote:
On Wed, 7 Feb 2001, Hugh Dickins wrote:
None of those optimizes this: I believe the semantics of "||" (don't
try next test if first succeeds) forbid the optimization "|" gives?
On Thu, 8 Feb 2001, David Weinehall wrote:
Well, after all, it's debugging code, and the code now is easy to read.
Your code, while more efficient, isn't. I think that clarity takes
priority over efficiency in non-critical code such as debugging
code. Of course, this is my personal
On Thu, 8 Feb 2001, Hugh Dickins wrote:
On Thu, 8 Feb 2001, David Weinehall wrote:
Well, after all, it's debugging code, and the code now is easy to read.
Your code, while more efficient, isn't. I think that clarity takes
priority over efficiency in non-critical code such as debugging
On Thu, 8 Feb 2001, Hugh Dickins wrote:
On Wed, 7 Feb 2001, Linus Torvalds wrote:
On Wed, 7 Feb 2001, Hugh Dickins wrote:
None of those optimizes this: I believe the semantics of "||" (don't
try next test if first succeeds) forbid the optimization "|" gives?
No. The
"Richard B. Johnson" wrote:
[snip]
Another problem with 'volatile' has to do with pointers. When
it's possible for some object to be modified by some external
influence, we see:
volatile struct whatever *ptr;
Now, it's unclear if gcc knows that we don't give a damn about
the
On Thu, 8 Feb 2001, Stephen Wille Padnos wrote:
"Richard B. Johnson" wrote:
[snip]
Another problem with 'volatile' has to do with pointers. When
it's possible for some object to be modified by some external
influence, we see:
volatile struct whatever *ptr;
Now, it's
"Richard B. Johnson" wrote:
On Thu, 8 Feb 2001, Stephen Wille Padnos wrote:
"Richard B. Johnson" wrote:
[snip]
Another problem with 'volatile' has to do with pointers. When
it's possible for some object to be modified by some external
influence, we see:
volatile
On Thu, 8 Feb 2001, Stephen Wille Padnos wrote:
"Richard B. Johnson" wrote:
On Thu, 8 Feb 2001, Stephen Wille Padnos wrote:
"Richard B. Johnson" wrote:
[snip]
Another problem with 'volatile' has to do with pointers. When
it's possible for some object to be modified by some
On Wed, 7 Feb 2001, Linus Torvalds wrote:
> No. The optimization is entirely legal - but the fact that
> "constant_test_bit()" uses a "volatile unsigned int *" is the reason why
> gcc thinks it can't optimize it.
This thing did attract me somewhat and I decided to learn a little about
On Wed, 7 Feb 2001, Hugh Dickins wrote:
>
> The "(1< activate_page_nolock() compiled -O2 -march=i686 with egcs-2.91.66 (RH7.0
> kgcc), gcc-2.96-69 (RH7.0 gcc+fixes), gcc-2.97 (gcc-snapshot-20010207-1).
>
> None of those optimizes this: I believe the semantics of "||" (don't
> try next test if
On Wed, 7 Feb 2001, Linus Torvalds wrote:
>
> I'd rather not do these kinds of things that the compiler should be able
> to trivially do for us.
>
> (gcc sometimes _does_ do these things. I've seen it. Why doesn't it do it
> here? Did you check the code? Have you asked the gcc lists?)
The "(1<
On Wed, 7 Feb 2001, Hugh Dickins wrote:
>
> Micro-optimization season?
I'd rather not do these kinds of things that the compiler should be able
to trivially do for us.
(gcc sometimes _does_ do these things. I've seen it. Why doesn't it do it
here? Did you check the code? Have you asked the
On Tue, 6 Feb 2001, Linus Torvalds wrote:
> > - if (bh->b_size % correct_size) {
> > + if (bh->b_size != correct_size) {
>
> Actually, I'd rather leave it in, but speed it up with the saner and
> fasterif (bh->b_size & (correct_size-1)) {
Micro-optimization season?
On Tue, 6 Feb 2001, Linus Torvalds wrote:
- if (bh-b_size % correct_size) {
+ if (bh-b_size != correct_size) {
Actually, I'd rather leave it in, but speed it up with the saner and
fasterif (bh-b_size (correct_size-1)) {
Micro-optimization season?
---
On Wed, 7 Feb 2001, Hugh Dickins wrote:
Micro-optimization season?
I'd rather not do these kinds of things that the compiler should be able
to trivially do for us.
(gcc sometimes _does_ do these things. I've seen it. Why doesn't it do it
here? Did you check the code? Have you asked the gcc
On Wed, 7 Feb 2001, Linus Torvalds wrote:
I'd rather not do these kinds of things that the compiler should be able
to trivially do for us.
(gcc sometimes _does_ do these things. I've seen it. Why doesn't it do it
here? Did you check the code? Have you asked the gcc lists?)
The
On Wed, 7 Feb 2001, Hugh Dickins wrote:
The "(1PG_bitshift)" part of it is done, sure; but I've rechecked
activate_page_nolock() compiled -O2 -march=i686 with egcs-2.91.66 (RH7.0
kgcc), gcc-2.96-69 (RH7.0 gcc+fixes), gcc-2.97 (gcc-snapshot-20010207-1).
None of those optimizes this: I
27 matches
Mail list logo
