lkml.org 
[lkml]   [1999]   [Nov]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] string.h speedup, cld-2.3.30-A1
On Sat, 27 Nov 1999, Linus Torvalds wrote:

> On Sat, 27 Nov 1999, Oliver Xymoron wrote:
>
> > On Sat, 27 Nov 1999, Ingo Molnar wrote:
> >
> > > much of the remaining 284 cld's is still unjustified, because '*a = *b;'
> > > type of structure copies are inlined by GCC. (GCC generates a cld because
> > > user-space has to be prepared to be interrupted by uncooperative signal
> > > handlers and the like).
> >
> > What!? A signal handler can change flags? Then there's a lot more for GCC
> > to worry about than the direction flag..
>
> A normal signal handler cannot change flags, because they will obviously
> be restored on signal exit.
>
> However, I'm not sure that "longjmp()" does the same. You'd have to check
> libc souces to see if setjmp saves the flags..

It doesn't appear to, at least according to bits/setjmp.h. Surely, any
point in a user app can quietly change flags, but Ingo's example of a
signal handler doing it seemed unlikely.

There's clearly no general fix for the existence of the direction flag
though, short of getting a non-x86 machine. We could lobby the GCC
folks for an -fassume-cld and maybe an -fpair-std, but it doesn't really
fix the problem.

--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site