Re: Newbie

[Paolo Bonzini]

If it is possible, I would like to begin with a small project to get
familiar with GCC code. I have been through the "Simple GCC projects"
web page and I would be interested in project such as "Convert
reorg.c to use the flow graph".

Could someone help me to get involved ?


I cannot but reinforce Laurynas' hints.  Unfortunately, you picked a 
rather complicated project, and I'm surprised that it is listed under 
"simple"!  In fact, it would probably be as easy to rewrite reorg.c 
completely; which is probably not the hardest GCC task on Earth, but not 
simple either.


You can look also at http://gcc.gnu.org/wiki/Speedup_areas including

* Bitmaps, also called sparse bit sets, are implemented using a linked 
list with a cache. This is probably not the most time-efficient 
representation, and it is not unusual for bitmap functions to show up 
high on the execution profile.  Try to understand which bitmaps can be 
replaced by ebitmaps.


* pointer_set and pointer_map are underused.

* Avoid recursive tree walks

* Rewrite for loops over the linked list of instructions (insns), so 
that they work on basic blocks and then on the insns for each basic block.


* cxx_binding should be 16 bytes, not 20.

Paolo

Re: Using crlibm as the default math library in GCC sources

[Uros Bizjak]

Richard Sandiford wrote:

Uros Bizjak <[EMAIL PROTECTED]> writes:
  
Forwarded is a short discussion with Mr. de Dinechin (forwarded with 
permission), where the possibility to import crlibm as the default gcc 
math library is discussed. I would like to ask members of the GCC SC for 
the opinion on the idea of adopting crlibm as the default math library. 
This way, the library can be compiled using all knowledge that gcc has 
about the target processor. As hinted in the attached message - 
autovectorization and perhaps recently introduced fixed-point 
infrastructure can be used effectively in the implementation of this 
library, as well as new AMD's FMA instructions.



That sounds like a great idea.  Do you know if the SC is already
considering it?  Or is it one of those cases where there needs
to be a bit more technical discussion first?
  


I don't have any further information from SC side. I have CC'd David in 
the hope that perhaps he can update us with some info.


Uros.

Tool chain configuration: GNU/* sharing stuff with GNU/Linux

[Thomas Schwinge]

Hello!

It is currently unclear whether GNU/Hurd, GNU/k*BSD, or GNU/* in general
should share stuff (like configuration branches inside `config.gcc',
files from `config/') with GNU/Linux.  This is -- because of the targets
being pretty much similar -- how it used to be done in the past.  But now
GCC's Andrew Pinski indicated that this shall no longer be desired, for
example in .

Contrary to Andrew, I would vote for all those GNU/* targets sharing the
same configuration machinery, as they are indeed meant to be as close to
each other as possible.

To give an example: all the GNU/* configurations use the `config/linux.h'
file, even though only one of the possible GNU/* configurations is
actually a Linux one.  Additionally the non-Linux ones currently have
files like `config/gnu.h' (for GNU/Hurd) or `config/kfreebsd-gnu.h' (for
GNU/kFreeBSD) to customize what is different for them from the main Linux
configuration file.

To state this intended similarity clearly, one could rename, e.g.,
`config/linux.h' to `config/gnu-shared.h' and then have a new (nearly
empty) file `config/linux.h' additionally to the existing `config/gnu.h',
`config/kfreebsd-gnu.h', etc. to do the remaining few customizations.

I'd offer (and already began) to work on this.  Please comment.


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: Tool chain configuration: GNU/* sharing stuff with GNU/Linux

[Samuel Thibault]

Thomas Schwinge, le Sun 11 Nov 2007 15:58:08 +0100, a écrit :
> To state this intended similarity clearly, one could rename, e.g.,
> `config/linux.h' to `config/gnu-shared.h' and then have a new (nearly
> empty) file `config/linux.h' additionally to the existing `config/gnu.h',
> `config/kfreebsd-gnu.h', etc. to do the remaining few customizations.

That'd make things much more clear (and fix the OPTION_GLIBC etc. bugs
btw).

Samuel

Re: Tool chain configuration: GNU/* sharing stuff with GNU/Linux

[Joseph S. Myers]

On Sun, 11 Nov 2007, Thomas Schwinge wrote:

> To give an example: all the GNU/* configurations use the `config/linux.h'
> file, even though only one of the possible GNU/* configurations is

GNU/Linux for Alpha, Power and SPARC don't use the shared file, so in 
those cases config/$cpu/linux.h has to duplicate a lot from it.

Also, some uClinux targets use this header, and some don't.

> To state this intended similarity clearly, one could rename, e.g.,
> `config/linux.h' to `config/gnu-shared.h' and then have a new (nearly
> empty) file `config/linux.h' additionally to the existing `config/gnu.h',
> `config/kfreebsd-gnu.h', etc. to do the remaining few customizations.

Perhaps it would make sense in the first instance to move just the subset 
that can be shared by *all* GNU/Linux targets (and is identical in 
config/alpha/linux.h, config/rs6000/linux.h, config/sparc/linux.h as well 
as in config/linux.h) into the new header - which *all* GNU/Linux targets 
would use - and then work out how to share the rest?

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: Using crlibm as the default math library in GCC sources

[Joe Buck]

On Sun, Nov 11, 2007 at 11:05:43AM +0100, Uros Bizjak wrote:
> Richard Sandiford wrote:
> >Uros Bizjak <[EMAIL PROTECTED]> writes:
> >  
> >>Forwarded is a short discussion with Mr. de Dinechin (forwarded with 
> >>permission), where the possibility to import crlibm as the default gcc 
> >>math library is discussed...
> >
> >That sounds like a great idea.  Do you know if the SC is already
> >considering it?  Or is it one of those cases where there needs
> >to be a bit more technical discussion first?
> 
> I don't have any further information from SC side. I have CC'd David in 
> the hope that perhaps he can update us with some info.

There hasn't been any SC discussion yet.  I suggest starting with
technical feasibility issues, so that there is a more concrete proposal to
consider.

Re: Designs for better debug info in GCC

[Mark Mitchell]

Alexandre Oliva wrote:

> 1. introduce, early in compilation (when entering SSA), annotations
> that map user-level variables whose location may vary throughout their
> lifetime to implementation-level variables or expressions at every
> point of assignment and PHI joins.
> 
> 2. keep those annotations accurate throughout compilation, without
> letting them interfere with optimizations, but making sure they are
> kept up-to-date or marked untrackable.
> 
> 3. in var-tracking, starting from the expressions in the annotations
> and their equivalent expressions computed with a dataflow-globalized
> cse analysis, emit traditional var-tracking var_location notes for all
> variables.  For variables that didn't start out as gimple regs, the
> current debug info behavior should be preserved.
> 
>> I think that most of the goals boil down to making sure that, at any
>> point in the program, the debug information for a variable meets the
>> following criteria:
> 
>> (a) if the variable has not been optimized away, gives the location
>> where that variable's current value can be found, or
>> (b) if the variable has been optimized away, and the value is not a
>> constant, says that the value is not available, or
>> (c) if the variable has been optimized away, but is a constant, says
>> what the constant value is
> 
> yes, except that instead of constant and constant value, I'd put it as
> 'computable expression from other live values'.
> 
> And I'd say "locations" rather than just "location".

I agree; those are generalizations, of which my bullets are a needlessly
constrained special case.  (Of course, we can gradually approach
"computable" by starting with "constant", and then adding more and more
refinement, if we like.)

>> But, how are we going to track this information?  Algorithmically, what
>> needs to change in the compiler to maintain this state?
> 
> Most optimizations passes must already update uses of gimple or pseudo
> regs they modify, so these will be taken care of automatically (which
> is why I chose this representation).

For the purposes of this discussion, let's assume that upon exit from
SSA we still have the information we need.  In particular, we know which
SSA names correspond to which user variables.  That tells us how to get
the values of user variables at the points where their values are
available, and also tells us when those variables do not have their
values available.

(We may already have lost some information, though.  For example, given:

  i = 3;
  f(i);
  i = 7;
  i = 2;
  g(i);

we may well have lost the "i = 7" assignment, so "i" might appear to
have the value "3" right before we assign "2" to it, if we were to
generate debug information right then.)

The reason I want to make that assumption is that the part of this where
the representation is in question is once we reach RTL, right?

I guess I still don't really understand what you're doing at the RTL
level.  I understand the objectives.  I understand some of the things
you're claiming as virtues of DEBUG_INSN.  What I don't understand is
how it's actually going to work.  What are the notes you're inserting?
Do they just say "here is an RTL expression for computing the value of
user-variable V at this point in the program"?  Why does it make sense
to have that, rather than notes on instructions that say what affect the
instruction has on user variables?  (For example, "this SET makes the
value of V unavailable".  Or "this SET makes the value of the V
available in the destination register"?)

As a meta-question, have you or anyone else on the list looked at the
literature (IEEE/ACM, etc.) or how other compilers handle these problems?

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: Designs for better debug info in GCC

[Mark Mitchell]

Robert Dewar wrote:
> Ian Lance Taylor wrote:
>> Alexandre Oliva <[EMAIL PROTECTED]> writes:
>>
>>> So...  The compiler is outputting code that tells other tools where to
>>> look for certain variables at run time, but it's putting incorrect
>>> information there.  How can you possibly argue that this is not a code
>>> correctness issue?
>>
>> I don't see any point to going around this point again, so I'll just
>> note that I disagree.
> 
> Well I very much agree.

The trick is that we're being asked to give a binary answer ("is it a
correctness issue?") when it's not really a binary issue.

Clearly, for some users, incorrect debugging information on optimized
code is not a terribly big deal.  It's certainly less important to many
users than that the program get the right answer.  On the other hand,
there are no doubt users where, whether for debugging, certification, or
whatever, it's vitally important that the debugging information meet
some standard of accuracy.

Part of my concern with this whole discussion is that we seem to be
saying we want the debugging information to be better, but not saying
very clearly what the requirements on better are.  Are we going to
consider it a bug if the value of a variable is unavailable, but the
debugging information says it is available?  (Yes, this seems like a bug
to me.)  What if an old value is available, but a simple-minded reading
of the program would have now assigned a new value?  (No, I wouldn't
consider this a bug.)  What if the value is available in two places, and
we only describe one of them?  (No, I wouldn't consider this a bug.)
What if the value is available, but we say that it isn't because we lost
track of it at some point?  (I would say "it depends".)

We could certainly track user variables through SSA and RTL, at least
insofar as knowing that some REGs refer to SSA names that refer to user
VAR_DECLs.  We can use dataflow analysis to compute where those values
(might) die.  Thus, we can probably do a reasonable job of guaranteeing
that when we say a variable is somewhere, it is in fact in that place.

I don't yet understand what else we're trying to do.

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713