skaller <[EMAIL PROTECTED]> writes:
> > As I said before, the register is only stolen for code which actually
> > uses TLS.
>
> So scanning that document, for x86_64, fs is used in startup
> code, presumably if, and only if, there is a linker section
> containing __thread variables?
Yes.
Ian
On Fri, 2007-11-02 at 22:35 -0700, Ian Lance Taylor wrote:
> skaller <[EMAIL PROTECTED]> writes:
>
> > Neko, for example, uses a register. AFAIK MLton does the
> > same kind of thing. If gcc team thinks ANY register is free
> > to steal they'd be wrong -- that doesn't mean it shouldn't
> > be use
On Fri, 2007-11-02 at 23:56 -0400, Robert Dewar wrote:
> skaller wrote:
> You really can't be serious in your comment about fs, if you
> understand the architecture ...
You're just not thinking the same way I am. A CPU has state,
the compiler and application program manage that state.
If the co
skaller <[EMAIL PROTECTED]> writes:
> Neko, for example, uses a register. AFAIK MLton does the
> same kind of thing. If gcc team thinks ANY register is free
> to steal they'd be wrong -- that doesn't mean it shouldn't
> be used, just that it definitely is NOT free.
To be clear, it is not the gcc
On Fri, 2007-11-02 at 23:54 -0400, Robert Dewar wrote:
> skaller wrote:
> > On Fri, 2007-11-02 at 18:45 -0700, Andrew Pinski wrote:
> >>> This is not true. If you use a register for any purpose like this,
> >>> it can't be used for anything else and that has a cost.
> >> This is a segment register
skaller wrote:
This is not true. If you use a register for any purpose like this,
it can't be used for anything else and that has a cost.
On x86_64 which I use, every register is valuable. Don't you dare
take one away, it would have a serious performance impact AND
it would stop ME using that r
skaller wrote:
On Fri, 2007-11-02 at 18:45 -0700, Andrew Pinski wrote:
This is not true. If you use a register for any purpose like this,
it can't be used for anything else and that has a cost.
This is a segment register. Please go and read about what segment
registers.
I know how the x86 wo
On Fri, 2007-11-02 at 18:45 -0700, Andrew Pinski wrote:
> > This is not true. If you use a register for any purpose like this,
> > it can't be used for anything else and that has a cost.
>
> This is a segment register. Please go and read about what segment
> registers.
I know how the x86 works
On Sat, 2007-11-03 at 12:27 +1100, skaller wrote:
> On Fri, 2007-11-02 at 10:29 -0700, Ian Lance Taylor wrote:
> Of course there is. It's called design by contract.
> I do it all the time. I am appalled at code bases like
> GTK and interfaces like OpenMP which get such really
> basic things wrong
On Fri, 2007-11-02 at 13:47 -0600, Joel Dice wrote:
> > So any (application) program needing TLS (other than the stack)
> > is automatically badly designed. I've been writing code for
> > three decades without using any global variables, ever since
> > I learned about re-entrancy.
>
> While I a
skaller <[EMAIL PROTECTED]> writes:
> On Fri, 2007-11-02 at 10:29 -0700, Ian Lance Taylor wrote:
> > skaller <[EMAIL PROTECTED]> writes:
> >
> > > On Fri, 2007-11-02 at 07:39 -0700, Ian Lance Taylor wrote:
> > > > skaller <[EMAIL PROTECTED]> writes:
> > >
> > > > In a C executable, TLS requires
On Fri, 2007-11-02 at 15:31 -0400, Robert Dewar wrote:
> Olivier Galibert wrote:
> There are lots of cases where global thread specific variables
> are useful in practice, ask anyone who has programmed real world
> large scale real time embedded programs.
No. And I have done just that myself. Th
> This is not true. If you use a register for any purpose like this,
> it can't be used for anything else and that has a cost.
This is a segment register. Please go and read about what segment
registers. They are not real registers and cannot be used for
anything except memory accesses. They da
On Fri, 2007-11-02 at 20:00 +0100, Olivier Galibert wrote:
> On Sat, Nov 03, 2007 at 03:38:51AM +1100, skaller wrote:
> > My argument is basically: there is no need for any such
> > feature in a well written program. Each thread already has
> > its own local stack. Global variables should not be u
On Fri, 2007-11-02 at 19:56 +0100, Olivier Galibert wrote:
> On Sat, Nov 03, 2007 at 03:31:14AM +1100, skaller wrote:
> > On Fri, 2007-11-02 at 07:39 -0700, Ian Lance Taylor wrote:
> > > I think you need to look at the TLS access code before deciding that
> > > it has bad performance.
> >
> > Yo
On Fri, 2007-11-02 at 10:29 -0700, Ian Lance Taylor wrote:
> skaller <[EMAIL PROTECTED]> writes:
>
> > On Fri, 2007-11-02 at 07:39 -0700, Ian Lance Taylor wrote:
> > > skaller <[EMAIL PROTECTED]> writes:
> >
> > > In a C executable, TLS requires one extra machine register.
> >
> > You mean gc
Snapshot gcc-4.3-20071102 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20071102/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
> Comments? Should I file a bug report?
Yes. It would help to know where the reference to ggc_free
in rtl.o comes from (i.e., look at preprocessed source for this
file). I don't think this file normally uses ggc_free().
Dave
--
J. David Anglin [EMAIL PROTECTED]
From: NightStrike <[EMAIL PROTECTED]>
Date: Fri, 2 Nov 2007 10:42:01 -0400
> I agree with you 100%. It has always been my view that if you can't
> compile fast enough, then get another machine and use distcc, or get a
> quad core and do make -j5, etc etc.
I have 64 cpu machines and use make -j64
On Sat, 3 Nov 2007, skaller wrote:
On Fri, 2007-11-02 at 10:46 -0400, Daniel Jacobowitz wrote:
On Fri, Nov 02, 2007 at 07:39:33AM -0700, Ian Lance Taylor wrote:
The only way I can interpret your comments is that you are assuming
that all TLS is Global Dynamic (e.g., accessed from a dlopen'ed sh
Olivier Galibert wrote:
On Sat, Nov 03, 2007 at 03:38:51AM +1100, skaller wrote:
My argument is basically: there is no need for any such
feature in a well written program. Each thread already has
its own local stack. Global variables should not be used
in the first place (except for signals etc
Sebastian Pop wrote:
On Oct 29, 2007 10:49 AM, Dorit Nuzman <[EMAIL PROTECTED]> wrote:
I wonder if it's versioning-for-aliasing (run-time dependence testing) that
was responsible for a lot of the new vectorizable loops
It is then possible that the code size noticeably increased. Toon
could
On Sat, Nov 03, 2007 at 03:38:51AM +1100, skaller wrote:
> My argument is basically: there is no need for any such
> feature in a well written program. Each thread already has
> its own local stack. Global variables should not be used
> in the first place (except for signals etc where
> there is no
On Sat, Nov 03, 2007 at 03:31:14AM +1100, skaller wrote:
> On Fri, 2007-11-02 at 07:39 -0700, Ian Lance Taylor wrote:
> > I think you need to look at the TLS access code before deciding that
> > it has bad performance.
>
> You already said it costs a register? That's a REALLY high cost
> to pay t
skaller <[EMAIL PROTECTED]> writes:
> On Fri, 2007-11-02 at 07:39 -0700, Ian Lance Taylor wrote:
> > skaller <[EMAIL PROTECTED]> writes:
>
> > In a C executable, TLS requires one extra machine register.
>
> You mean gcc?
I don't understand the question. I mean in a C/C++ executable which
use
On Fri, 2007-11-02 at 10:46 -0400, Daniel Jacobowitz wrote:
> On Fri, Nov 02, 2007 at 07:39:33AM -0700, Ian Lance Taylor wrote:
> > The only way I can interpret your comments is that you are assuming
> > that all TLS is Global Dynamic (e.g., accessed from a dlopen'ed shared
> > library). But stac
On Fri, 26 Oct 2007, Diego Novillo wrote:
> So, I think the problem goes a bit beyond mere documentation of how a
> module works at a high level. I would like to have a navigable
> document that also describes the flow of things, interfaces and
> helpers. Starting at main.c:main() and ending at t
On Fri, 2007-11-02 at 07:39 -0700, Ian Lance Taylor wrote:
> skaller <[EMAIL PROTECTED]> writes:
> In a C executable, TLS requires one extra machine register.
You mean gcc?
> TLS
> variables are accessed via offsets from that register. So what's the
> significant difference between that and
> "timtuun" == timtuun <[EMAIL PROTECTED]> writes:
timtuun> I was wondering if there is a particular reason why object
timtuun> name in dependency output doesn't include the directory where
timtuun> the output is written?
Just conservatism -- the options have worked this way for a long time.
2007/11/2, NightStrike <[EMAIL PROTECTED]>:
> On 11/1/07, Ted Byers <[EMAIL PROTECTED]> wrote:
> > --- David Miller <[EMAIL PROTECTED]> wrote:
> > > ...
>
> I agree with you 100%. It has always been my view that if you can't
> compile fast enough, then get another machine and use distcc, or get a
On Fri, Nov 02, 2007 at 07:39:33AM -0700, Ian Lance Taylor wrote:
> The only way I can interpret your comments is that you are assuming
> that all TLS is Global Dynamic (e.g., accessed from a dlopen'ed shared
> library). But stack based thread local storage won't work for
> dlopen'ed shared librar
On 11/1/07, Ted Byers <[EMAIL PROTECTED]> wrote:
> --- David Miller <[EMAIL PROTECTED]> wrote:
> > From: NightStrike <[EMAIL PROTECTED]>
> > Date: Thu, 1 Nov 2007 22:34:33 -0400
> >
> > > I think what is more important is the resulting
> > binary -- does it
> > > run faster?
> >
> > The answer to t
skaller <[EMAIL PROTECTED]> writes:
> A really cool (non-Posix) implementation would put TLS globals
> on the stack base .. but this does require at least one extra
> machine register in languages like C which don't provide
> a static display (pointer to parent function). For languages
> that do,
Hi, Ramana,
I tried the trunk version with/without your patch. It still produces
the same code as gcc4.2.2 does. In auto-inc-dec.c, the comments say
*a
...
a <- a + c
becomes
*(a += c) post
But the problem is after Tree-SSA pass, there is no
Hi Bingfeng,
On 11/2/07, Bingfeng Mei <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I look at the following the code to see what is the difference between
> GCC4 and GCC3 in using POST_INC address mode (or other similar modes).
>
> void tst(char * __restrict__ a, char * __restrict__ b){
> *a++ = *b++
Hello,
I look at the following the code to see what is the difference between
GCC4 and GCC3 in using POST_INC address mode (or other similar modes).
void tst(char * __restrict__ a, char * __restrict__ b){
*a++ = *b++;
*a++ = *b++;
*a++ = *b++;
*a++ = *b++;
*a++ = *b++;
*a++ = *b++;
On 11/1/07, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> Just go ahead and kill it. I would preffer to remove the whole hook,
> but we still keep some non-GIMPLE expressions in static initializers :(
Yeah, that's too bad.
Attached is the patch I committed, tested on x86_64. This fixes the
latent b
Hi.
I was wondering if there is a particular reason why object name in
dependency output doesn't include the directory where the output is
written? For example when compiling vim version 7.1 I get the following
result.
[EMAIL PROTECTED] vim71]$ gcc --version
gcc (GCC) 4.1.2 20070626 (Red Hat 4.1.
> Questions:
> * shorten_branches() computes sizes of instructions so I know what the
> distance is between a jump instr and its target label. But how do I know
> what is the maximum distance each kind of branch can safely take?
> bb-reorder.c assumes that its only when cold/hot partitions a
On Thu, 2007-11-01 at 21:02 -0700, Gary Funck wrote:
> On Thu, Oct 18, 2007 at 11:42:52AM +1000, skaller wrote:
> >
> > DO you know how thread local variables are handled?
> > [Not using Posix TLS I hope .. that would be a disaster]
>
> Would you please elaborate?
Sure ..
> What's wrong with
40 matches
Mail list logo
