I have some problems in global register allocation phase.
I have described some simple architecture using machine description and target
macro file. I use gnu GCC version 4.1.1.
But, "can't combine" message is printed out in *.c.37.greg file in global
register allocation phase. After i have tra
On Mar 20, 2007, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> (I fully expect that -- without change -- the traditional GCC build
> process, using parallel make, will become bound mostly by the serial
> nature of the configure scripts, rather by the actual compilation of the
> compiler and runtime l
On Mar 20, 2007, [EMAIL PROTECTED] (Richard Kenner) wrote:
> infringes our copyright
> Patent law
Please be careful to not spread the confusion that already exists
between these unrelated laws.
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member
Hi all,
I need to implement profiling support for my backend (GCC 4.1.1).
There is only limited information in GCC Internals to define the
following macros (FUNCTION_PROFILER, PROFILE_HOOK ,NO_PROFILE_COUNTERS
& PROFILE_BEFORE_PROLOGUE) to add profiling support. I need to know
the following detai
Wow, lots of comments there, Mike ;-)
We saw a 41% speed-up for SimpleText, a 110x peak speedup for
and (cstdlib). A C++ Carbon hello world was 91x faster,
peak. C hello world was the same speed. Peak speedups for C 2x,
for C++ 142x.
Cool! After some measurements (-ftime-report, tee, gre
On Mar 20, 2007, at 4:39 PM, Karthikeyan M wrote:
Are these macros not a part of 4.1.2 ?
4.1.2, what's that?! :-)
I just picked up the tarball of the 4.1.2-core source.
Pick something that says 2007 and 4.3... :-)
In general, new work is best done against the top of the tree, that
is t
On Mar 20, 2007, at 1:07 AM, Simon Brenner wrote:
I propose to implement incremental parsing in C++
Sounds like a multi-person, multi-year project.
We did something like this a while ago, called the compile server.
The idea was to be able to advance through unchanged portions of code
and
Are these macros not a part of 4.1.2 ?
I just picked up the tarball of the 4.1.2-core source.
Which release has this code ?
Thanks a lot.
On 3/20/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
On 3/20/07, Karthikeyan M <[EMAIL PROTECTED]> wrote:
> Thanks.
> Where exactly should I be looking?
cg
On 3/20/07, Karthikeyan M <[EMAIL PROTECTED]> wrote:
Thanks.
Where exactly should I be looking?
cgraph.c, cgraphunit.c, cgraph.h
see cgraph_varpool_nodes, FOR_EACH_STATIC_VARIABLE (static here means
having scope greater than a single function, it does not mean "all
variables declared static in C
On Tue, 20 Mar 2007, Nicholas Nethercote wrote:
GCC is a very ambitious compiler:
- it supports a lot of platforms
- it supports a lot of languages
However, most users do not use most of those combinations. The problem is
that supporting all these combinations hurts the specific combinations
"Doug Gregor" <[EMAIL PROTECTED]> writes:
> On 20 Mar 2007 17:04:56 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
> > That defered parsing might work with C (I don't really know), but it
> > certainly is problematic with C++ because there are bindings that
> > need to be in overload sets, and
On 20 Mar 2007 17:04:56 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
That defered parsing might work with C (I don't really know), but it
certainly is problematic with C++ because there are bindings that
need to be in overload sets, and you cannot accurately capture those if
you don't parse
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> | Another approach I've considered is to skip parsing functions until
> | they are needed. Since the parser dominates the -O0 compilation time,
> | and since large C++ projects have hundreds of inline functions which
> | are never needed by any parti
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
| "Simon Brenner" <[EMAIL PROTECTED]> writes:
|
| > I propose to implement incremental parsing in C++ (through hand-waving, C++
has
| > been decided to be the language most in need of incremental parsing),
similar to
| > the approach in article [1].
Thanks.
Where exactly should I be looking?
Will the cgraph nodes also have global declarations that are never
used inside any
function .
On 3/20/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
On 3/20/07, Dave Korn <[EMAIL PROTECTED]> wrote:
> On 19 March 2007 22:16, Karthikeyan M wrote:
>
> > What
On 3/20/07, Dan Nicolaescu <[EMAIL PROTECTED]> wrote:
"Doug Gregor" <[EMAIL PROTECTED]> writes:
> On 3/20/07, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> > Would you please consider testing the 16 bit tree code as you did for 8 vs
> > 9 bits? Perhaps you could also measure memory usage fo
"Doug Gregor" <[EMAIL PROTECTED]> writes:
> On 3/20/07, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> > Would you please consider testing the 16 bit tree code as you did for 8 vs
> > 9 bits? Perhaps you could also measure memory usage for all three
> > solutions?
>
> I've measured the
On 20/03/07, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
On Tue, Mar 20, 2007 at 11:04:16AM -0600, Kevin Handy wrote:
> >#define LANG_TREE_CODE(NODE) (TREE_CODE (NODE) == LANG_CODE ?
> >((tree_with_subcode *)(NODE))->subcode : TREE_CODE (NODE))
> >
> This subcode idea feels like a bug attractor to m
On 3/20/07, Dave Korn <[EMAIL PROTECTED]> wrote:
On 19 March 2007 22:16, Karthikeyan M wrote:
> What should I do if I want a list of all file-scope variables inside
> my own pass ?
>
> The file_scope variable is local to c-decl.c . Is there a reason why
> the scope holding variables are local to
On Tue, Mar 20, 2007 at 11:04:16AM -0600, Kevin Handy wrote:
> >#define LANG_TREE_CODE(NODE) (TREE_CODE (NODE) == LANG_CODE ?
> >((tree_with_subcode *)(NODE))->subcode : TREE_CODE (NODE))
> >
> This subcode idea feels like a bug attractor to me.
>
> For example: #defines have enough problems wi
> Different people will give you different answers about different
> situations. There is no clear answer. This mailing list is
> unfortunately not the right place to ask GPL licensing questions.
>
> I would suggest the gnu.misc.discuss newsgroup. Or asking the Free
> Software Foundation direct
Jakub Jelinek wrote:
On Tue, Mar 20, 2007 at 09:37:38AM -0400, Doug Gregor wrote:
Even if we only use subcodes for the less often used codes, I think we
still take the performance hit. The problem is that it's very messy to
I'm sure smaller hit than when going to 9 bit tree code, and o
Joe Buck wrote:
> If you want to be a working programmer in ten years, you need to start
> thinking about parallel programming.
Yes, I'm well aware of the technology roadmaps for CPUs. But, I don't
think that's got a big impact here; the parallelism is also going to
apply to the software build
On Mon, Mar 19, 2007 at 08:16:42PM -0700, Mark Mitchell wrote:
> Nicholas Nethercote wrote:
>
> > As for what is best to do, I don't know. But I do know that complexity
> > is bad, and that GCC is very complex. You are absolutely right about
> > there being hard limits. There are trade-offs req
"Simon Brenner" <[EMAIL PROTECTED]> writes:
> I propose to implement incremental parsing in C++ (through hand-waving, C++
> has
> been decided to be the language most in need of incremental parsing), similar
> to
> the approach in article [1]. Basically, a diff algorithm is run on the
> charact
On Tue, Mar 20, 2007 at 09:37:38AM -0400, Doug Gregor wrote:
> Even if we only use subcodes for the less often used codes, I think we
> still take the performance hit. The problem is that it's very messy to
I'm sure smaller hit than when going to 9 bit tree code, and on i386/x86_64
maybe even than
"Nick Rolins" <[EMAIL PROTECTED]> writes:
> If I make a program that calls by command line the gcc executable with
> -fdump-translation-unit option and parses the dump output file,
> does it have to adhere to the GPL license ?
>
> If it doesn't have to adhere to the GPL license, how about if my
>
Hi,
If I make a program that calls by command line the gcc executable with
-fdump-translation-unit option and parses the dump output file,
does it have to adhere to the GPL license ?
If it doesn't have to adhere to the GPL license, how about if my
program gets the dump output by a pipe or a sock
On 3/20/07, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
Would you please consider testing the 16 bit tree code as you did for 8 vs
9 bits? Perhaps you could also measure memory usage for all three
solutions?
I've measured the 8 vs. 9-bit solutions: they have identical memory footprints.
I thi
On 3/20/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
On 3/20/07, Doug Gregor <[EMAIL PROTECTED]> wrote:
> > So the memory hit shouldn't be
> > as big as e.g. going to 16 bit tree codes if that means increasing the size
> > of most of the trees the compiler uses.
>
> Yes, this is true.
But this
On 3/20/07, Doug Gregor <[EMAIL PROTECTED]> wrote:
> So the memory hit shouldn't be
> as big as e.g. going to 16 bit tree codes if that means increasing the size
> of most of the trees the compiler uses.
Yes, this is true.
But this could be solved if all LANG_TREE_x bits could move to
language
On 3/20/07, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
On Tue, Mar 20, 2007 at 08:56:10AM -0400, Kaveh R. GHAZI wrote:
> We've been considering two solutions, the 9 bit codes vs the subcode
> alternative.
>
> The 9 bit solution is considered simpler and without any memory penalty
> but slows down t
On Tue, Mar 20, 2007 at 08:56:10AM -0400, Kaveh R. GHAZI wrote:
> We've been considering two solutions, the 9 bit codes vs the subcode
> alternative.
>
> The 9 bit solution is considered simpler and without any memory penalty
> but slows down the compiler and doesn't increase the number of codes v
On Tue, 20 Mar 2007, Doug Gregor wrote:
> On 3/20/07, Brooks Moses <[EMAIL PROTECTED]> wrote:
> > Steven Bosscher wrote:
> > > On 3/20/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> > >> I think it's fair for front ends to pay for their
> > >> largesse. There are also relatively cheap changes in
On 3/20/07, Brooks Moses <[EMAIL PROTECTED]> wrote:
Steven Bosscher wrote:
> On 3/20/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> I think it's fair for front ends to pay for their
>> largesse. There are also relatively cheap changes in the C++ front end
>> to salvage a few codes, and postpon
On 19 March 2007 22:16, Karthikeyan M wrote:
> What should I do if I want a list of all file-scope variables inside
> my own pass ?
>
> The file_scope variable is local to c-decl.c . Is there a reason why
> the scope holding variables are local to c-decl.c ?
Because we want to keep front-, mid
On 19 March 2007 22:41, Gabriel Dos Reis wrote:
>
> yeah, the trouble is that we don't seem to agree on what is good for
> long-term, or if and when we agree whether we would find and allocate
> resources to implement the solution. So, we end up accumulating
> small% regressions over small% regr
2007/3/18, Christian Joensson <[EMAIL PROTECTED]>:
Under cygwin, I get a stage 2 and 3 comparison failure that's not
supposed to be there...
Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
warning: ./cc1obj-checksum.o differs
warning: ./cc1objplus-checksum.o differs
warning: ./cc1plus
>
> I've been using binutils 2.17 on various distributions of powerpc64-linux
> and have had no problem with it.
I used binutils 2.15. I guess this is the problem.
Thanks,
Revital
>
> Janis
Steven Bosscher wrote:
On 3/20/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
I think it's fair for front ends to pay for their
largesse. There are also relatively cheap changes in the C++ front end
to salvage a few codes, and postpone the day of reckoning.
I think that day of reckoning will c
--Rationale-- (to be expanded in the actual application)
* Parsing of C++ is slow
* On large projects, compile times often dominate the compile/edit/debug cycle
* Changes in source are often small and isolated
* Preprocessed compilation units are often huge - esp. compared to the
size of changes.
41 matches
Mail list logo
