Re: [RFC] Optimization Diary

[Richard Earnshaw]

On Wed, 2006-06-07 at 01:36, Geoffrey Keating wrote:
> On 06/06/2006, at 5:25 PM, Andrew Pinski wrote:
> 
> >> On 06/06/2006, at 5:20 PM, Andrew Pinski wrote:
> >>
>  Right above, you said "We control the debug output machinery
>  generating this, and can simply tell it to only deal in one
>  language."  Here, you seem to be implying that the messages  
>  should be
>  localised in the language the compiler is going to output messages
>  in.  I suppose you could output both, but that still bloats object
>  files more than just using numbers.
> >>>
> >>> Just output in English and let the IDE or the other tools translate
> >>> it.
> >>
> >> What's the difference between that and just outputting a number and
> >> letting the IDE or other tool translate it?  Either way, you're going
> >> to need a fixed set of strings or numbers to translate.
> >
> > Say I want to add a new one, I have to go through a committee with the
> > number system while with a string I don't.
> 
> I don't see how making it a string makes this different.  Either your  
> new string will be a standard string or it won't.  Either your new  
> number will be a standard number or it won't.  If you want it to be  
> standard, you have to go through the committee.

If I'm using a french translation and I see 'Variable optimized away' I
might get irritated but I can try to translate it.  If I see
'Unrecognized optimization code 33' I've got no chance.

Using string codes allows a more relaxed propagation model for the
translations (provided we don't keep tweaking the strings).

R.

Re: Modifying ARM code generator for elimination of 8bit writes - need help

[Richard Earnshaw]

On Wed, 2006-06-07 at 06:22, Wolfgang Mües wrote:
> Rask,
> 
> On Tuesday 06 June 2006 21:33, Rask Ingemann Lambertsen wrote:
> > > > +   swp%?b\\t%1, %1, %0\;ldr%?b\\t%1, %0"
> > >
> > > You should get a price for cleverness here!
> >
> > Thanks! Indeed it looks good until you think of volatile variables.
> 
> Because volatile variables can change their values from another thread, 
> and the readback will be false. Oh.
> 

It's quite simple.  Declaring a volatile char will be unpredictable in
your compilation environment (in the same way as volatile short was on
pre-v4 ARM devices).

However, for some uses (eg device drivers) you could explicitly use an
asm that did a ldrb/strb sequence (if some parts of your memory system
support that.

R.

Re: [wwwdocs] Complete revamp of our web site

[Gerald Pfeifer]

On Mon, 5 Jun 2006, Martin Michlmayr wrote:
> * Gerald Pfeifer <[EMAIL PROTECTED]> [2006-06-05 22:51]:
>>  GCC, the GNU Compiler Collection
> How about a dash here rather than a comma?  Looks nicer imho:
> |  GCC - the GNU Compiler Collection

The reason I avoid the dash is that, per the FSF guidelines, the
title continues with " - GNU Project - Free Software Foundation".

This is not visible in the plain HTML source, but added automagically
on the server.

We could omit one of GCC or GNU Compiler Collection from the title, or
use "GNU Compiler Collection (GCC)" or "GCC (GNU Compiler Collection)".
I have a slight preference for keeping the status quo, but don't feel
too strongly about it.

Gerald

Re: Fw: GCC 4.2 Status Report (2006-06-04)

[Ayal Zaks]

"Richard Guenther" <[EMAIL PROTECTED]> wrote on 06/06/2006
16:58:27:

> On 6/6/06, Ayal Zaks <[EMAIL PROTECTED]> wrote:
> >
> > > This status report has been a long time coming, for which I
apologize.
> > >
> > > As fwprop is no longer on the table for 4.2, and as the vectorizer
> > > improvements seem to have stalled due to a combination of lack of
review
> > > and Dorit's leave,
> >
> > That is unfortunate. Dorit did make a sincere effort to prepare her
patches
> > long ago (mid February) well before leaving, and Victor has been
constantly
> > pinging for reviews, ready to address them.
>
> 
> Maybe you can look at some of the regressions of the vectorizer first,
> instead of
> adding new features without first addressing regressions?
>
> This could build up some trust that the newly added code will actually
> be maintained
> in the future.
> 
>
> For a quick bugzilla search, use the 4.2 regressions link on the
> gcc.gnu.org page
> and modify it to include "-ftree-vectorize" in the bug description.  I
> count 3 P1 and
> 3 P2 regressions.
>
> Richard.


This is not entirely fair.

We regretfully have been neglecting PRs recently, partly because of dorit's
leave, but in the past we have always addressed PRs and maintained our
code.  During the time that PRs weren't being addressed by us we also
haven't submitted any new features to mainline.  In fact, if you check,
you'll find that when the features in question were submitted (around
February), we also gave a lot of attention to PRs.  Having said that, we
should and are looking into current PRs; we definitely have a strong
interest in seeing them resolved.

Ayal.

Re: [wwwdocs] Complete revamp of our web site

[Martin Michlmayr]

* Gerald Pfeifer <[EMAIL PROTECTED]> [2006-06-07 11:38]:
> I have a slight preference for keeping the status quo

OK.
-- 
Martin Michlmayr
http://www.cyrius.com/

RTL explaination

[kernel coder]

hi,
I'm trying to understand the rtl genrated by gcc for mips processor.I
have read gcc internals by Richard Stallman but there  are still some
confusions in the rtl language.

Following is a snippet of code which i'm trying to understand.

(insn 9 6 10 (nil) (set (reg:SI 182)
   (mem/f:SI (symbol_ref:SI ("a")) [0 a+0 S4 A32])) -1 (nil)
   (nil))

In the above code following part is still unclear to me

[0 a+0 S4 A32])) -1 (nil)
   (nil))

Following is the c code for which above rtl is generated :

int a;
main()
{
a=a+1;
}


thanks,
shahzad

Re: RTL explaination

[Steven Bosscher]

On 6/7/06, kernel coder <[EMAIL PROTECTED]> wrote:

hi,
I'm trying to understand the rtl genrated by gcc for mips processor.I
have read gcc internals by Richard Stallman


His name may be on it, but it's actually supposed to be maintained by
the gcc team.

I say "supposed" because apparently you can't find the answer to your
problem in the internals manual.  That makes me wonder, could you
check whether MEM_ATTRS is documented in that manual?  Because...


[0 a+0 S4 A32])) -1 (nil)
   (nil))


...in your insn...:


(insn 9 6 10 (nil) (set (reg:SI 182)
   (mem/f:SI (symbol_ref:SI ("a")) [0 a+0 S4 A32])) -1 (nil)
   (nil))


...are the MEM_ATTRS for the SET_SRC of this set (the "(mem ...)"
bit).  MEM_ATTRS are mainly used to store alias analysis information.
See rtl.h and rtl.def, and if you feel like this is your lucky day
then you could look at alias.c too.

Gr.
Steven

Re: RTL explaination

[David Edelsohn]

> kernel coder writes:

kernel> In the above code following part is still unclear to me

kernel> [0 a+0 S4 A32]

The values in order represent:

Alias Set
Offset from a base expression, if part of a larger object
Size
Alignment

David

RE: Inline memcpy in GCC 4.1.1

[Jon Beniston]

> 
> In http://gcc.gnu.org/ml/gcc/2006-06/msg00185.html, your wrote:
> 
> > So, two questions: any idea why 4.1.1 is no longer able to 
> > automatically inline memcpys and why is the source operand for 
> > movmemsi not know to be as widely aligned as it actually is?
> 
> See PR middle-end/27226
> 

Thanks a lot, that patch fixed it.

Cheers,
Jon

Thoughts about GC root sets

[Laurynas Biveinis]

Daniel, first of all, how would you prefer to communicate on general
GCC issues? Is it OK to send e-mail to you and to gcc mailing list, or
should I send such mails to gcc mailing list only?

Some of the GCC roots live on the heap memory, e.g. ident_table. These
are not found by Boehm's GC by default. I've started fixing such
places by registering these additional roots. But it got me thinking:
how do the old GCC garbage collectors know about those roots? I do not
see any root registration calls, but maybe I do not know where to
look. They cannot handle such roots automatically because they don't
intercept ordinary malloc calls and do not track information about
such regions. So that's puzzling me. Any hints would be appreciated.

--
Thanks in advance,
Laurynas

Re: Thoughts about GC root sets

[Daniel Berlin]

Laurynas Biveinis wrote:
> Daniel, first of all, how would you prefer to communicate on general
> GCC issues? Is it OK to send e-mail to you and to gcc mailing list, or
> should I send such mails to gcc mailing list only?

Copying me is fine for me.


> 
> Some of the GCC roots live on the heap memory, e.g. ident_table. These
> are not found by Boehm's GC by default. I've started fixing such
> places by registering these additional roots. But it got me thinking:
> how do the old GCC garbage collectors know about those roots?

There is a root list, generated by gengtype from parsing the files
looking for those GTY markers.


 I do not
> see any root registration calls, but maybe I do not know where to
> look. 


So, if you look at ggc_mark_roots, you can see the walker that is
walking the root table.

If you look in your *build* directory, and grep for ggc_root_tab, you
will see where the roots are.

Again, these are all auto-generated from gengtype.  You can simply
register them with boehm once gcc starts, because the root set never
changes.

One thing i should mention to you at this point, if you haven't
discovered yet, is that it is *not safe* to do collections in between
ggc_collect calls right now (IE when ggc_alloc is called).

At least, not without walking *everything* looking around for possible
roots, because places don't expect ggc_alloc'd memory without a "real"
root (IE registered in the root table) memory to disappear until the
next ggc_collect call.

Thus, it is common practice for intra-pass garbage is just allocated
without a root using ggc_alloc, and expected to disappear by virtue of
having no registered root the next time ggc_collect is called.

Re: Thoughts about GC root sets

[Paolo Bonzini]

Some of the GCC roots live on the heap memory, e.g. ident_table. These
are not found by Boehm's GC by default. I've started fixing such
places by registering these additional roots. But it got me thinking:
how do the old GCC garbage collectors know about those roots? I do not
see any root registration calls, but maybe I do not know where to
look. They cannot handle such roots automatically because they don't
intercept ordinary malloc calls and do not track information about
such regions. So that's puzzling me. Any hints would be appreciated.


Labas Laurynas,

If you look closer at stringpool.c, you can see this:

  /* Mark the trees hanging off the identifier node for GGC.  These are
 handled specially (not using gengtype) because of the special
 treatment for strings.  */

  void
  ggc_mark_stringpool (void)
  {
ht_forall (ident_hash, mark_ident, NULL);
  }

  /* Mark an identifier for GC.  */

  static int
  mark_ident (struct cpp_reader *pfile ATTRIBUTE_UNUSED, hashnode h,
  const void *v ATTRIBUTE_UNUSED)
  {
gt_ggc_m_9tree_node (HT_IDENT_TO_GCC_IDENT (h));
return 1;
  }

You can grep for ggc_mark_stringpool now, and you'll get to where other 
roots are taken from the tables that gengtype produces.  I'm not very 
familiar with the gengtype code and I haven't seen yours, so I can't 
tell you offhand how you can handle other GTY(()) variables.  This one 
*is* special though.


Paolo

RFC: x86 Linux stack alignment requirement

[H. J. Lu]

The x86 psABI is very old and doesn't cover XMM registers. I'd like to
update x86 Linux calling convention for XMM register usage. I am not
sure if I should update stack alignment requirement.

The x86 psABI only requires 4 byte aligned stack. But the current gcc
assumes that the satck of a function which uses XMM register is 16
byte aligned. That means gcc may generate x86 codes which are psABI
compliant, but will crash at runtime:

[EMAIL PROTECTED] stack]$ cat m.c
#include 
extern char *e1 (void);
int
main ()
{
  printf ("%s\n", e1 ());
  return 0;
}
[EMAIL PROTECTED] stack]$ cat x.c
#include 
extern char *e1 (void);
char *e1 (void)
{
  volatile __m128 dummy = _mm_set_ps1(0.f);
  return "OK";
}
[EMAIL PROTECTED] stack]$ make
gcc -Os   -c -o m.o m.c
gcc -O -msse2   -c -o x.o x.c
gcc -o m m.o x.o
./m
make: *** [all] Segmentation fault
[EMAIL PROTECTED] stack]$

We have several choices for stack alignment requirement

1. Leave it unchanged. Gcc can do
a. Nothing. Let the program crash.
b. Align stack to 16byte if XMM registers are used locally and
   aren't passed down as function arguments.
2. Update stack alignment requirement to 16byte and gcc will align
stack at 16byte by default, including -Os.


H.J.

Re: RFC: x86 Linux stack alignment requirement

[Sandro Tolaini]

On 07/giu/2006, at 18:22, H. J. Lu wrote:


The x86 psABI is very old and doesn't cover XMM registers. I'd like to
update x86 Linux calling convention for XMM register usage. I am not
sure if I should update stack alignment requirement.


Maybe you'll want to check how this is handled in Darwin/x86, which  
requires 16-byte stack alignment because it is internally using XMM  
registers.


Cheers,
  Sandro

Re: Thoughts about GC root sets

[Laurynas Biveinis]

Hi,


There is a root list, generated by gengtype from parsing the files
looking for those GTY markers.

So, if you look at ggc_mark_roots, you can see the walker that is
walking the root table.

If you look in your *build* directory, and grep for ggc_root_tab, you
will see where the roots are.


Thanks, that's exactly what I didn't know :)


Again, these are all auto-generated from gengtype.  You can simply
register them with boehm once gcc starts, because the root set never
changes.


As far as I can understand, current GGC-ors do not simply register
them as a additional roots - they walk them all the way down by the
pointers and mark stuff as required during collection. Now, if I add
the roots to Boehm's GC, this traversal and marking will be done
internally by Boehm's GC. The question is, does GCC have any data
structures looking like this: root -> some GC'ed memory -> some
malloc'ed memory -> some GC'ed memory (or similar)?  Such cases should
be OK with current GGC schemes, but Boehm's GC would be lost here.


One thing i should mention to you at this point, if you haven't
discovered yet, is that it is *not safe* to do collections in between
ggc_collect calls right now (IE when ggc_alloc is called).


Noted. I didn't know that.

--
Laurynas

Re: [RFC] Optimization Diary

[Tom Tromey]

> "Dan" == Daniel Berlin <[EMAIL PROTECTED]> writes:

Dan> You still need to be able to display the message for each number in all
Dan> the languages you want, so it's going to be stored somewhere, you
Dan> haven't solved the problem, just moved it completely to the consumer.

Usually I'm not a fan of using numbers instead of strings.  But in
this particular case I think it does make sense.

One reason is that numbers are compiler-independent.  This means that
the IDE can provide its preferred text for each message and this will
work regardless of what compiler is in use.

With strings you either need to enumerate all possible strings or you
need access to the compiler's message catalog -- but either of these
is hard to do in a compiler-independent way.

Dan> I have a very hard time believing that compiling and outputting messages
Dan> in one language, and having someone who can't read those messages
Dan> optimize and profile your application in another language, is a
Dan> significant enough use case to be worried about.

Yes, I agree that this is scenario probably does not occur often.
Nevertheless I think we should aim for maximum usability -- it is a
bad idea in general to design something knowing about a losing i18n
case... usage frequencies change.

Dan> It also has almost zero hope of working over multiple compiler versions,
Dan> being future proof in general, and not having other compiler vendors
Dan> fight over message number namespace.

The maintenance issue is a major one.  This document definitely needs
to address this, and not just in some theoretical way.  Otherwise,
chaos ensues.  I'm sure we've all seen the consequences here plenty of
times, enough to insist on a solution.

Tom

Re: RFC: x86 Linux stack alignment requirement

[H. J. Lu]

On Wed, Jun 07, 2006 at 06:43:50PM +0200, Sandro Tolaini wrote:
> 
> On 07/giu/2006, at 18:22, H. J. Lu wrote:
> 
> >The x86 psABI is very old and doesn't cover XMM registers. I'd like to
> >update x86 Linux calling convention for XMM register usage. I am not
> >sure if I should update stack alignment requirement.
> 
> Maybe you'll want to check how this is handled in Darwin/x86, which  
> requires 16-byte stack alignment because it is internally using XMM  
> registers.
> 

They try to support 4byte alignment legacy code with

http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00526.html

There are 2 different, but related questions:

1. Should Linux require gcc generates 16byte aligned stack?
2. How should Linux support 4byte alignment code?


H.J.
H.J.

Re: [RFC] Optimization Diary

[Devang Patel]

Andrew Pinski wrote:


On Jun 6, 2006, at 10:34 PM, Devang Patel wrote:


Andrew Pinski wrote:


On Jun 6, 2006, at 9:49 PM, Devang Patel wrote:

We can allocate space in numbering for vendor extensions.


What happens when you compile two sources with two different 
compilers and they

use the same number for vendor extension?


What happens when another compiler uses 0x4104 TAG value for
something else and GCC uses it for DW_TAG_GNU_BINCL ?


Not my fault 


Read your question, my reply question and your answer.

and not really related because we are creating a new standard and
don't want to repeat this mistake, messages don't have this issue.


You just end up with weird results
in the IDE or performance analysis program.
Also what happens after you fill up the vendor extension range?
What happens when vendor extension range for TAGs and Attributes are 
full ?


Who cares,


Again, read your question, my reply question and your answer.
Tell me, why should n't I laugh ? :) :)

Is it constructive (and appropriate? but hey I'm DWARF newbie myself) to 
declare

DWARF standard limited and full of mistakes ?
we are trying making something which is useful and not making 
something which

is going to be limited.

Also what happens when you change your compiler but not IDE, but you 
don't

want to update the IDE?

What happens when GCC adds new DWARF extension but you do not want
to update GDB ?


Again, we are trying to make something useful and extendable. If you 
don't

care about usefulness and extendibility then go ahead and use numbers.


Read proposal again. There is one thing in proposal that allows to 
handle similar

situation for diary messages in nicer way.


Having the message gets rid of having duplicated code in each program 
that processes

the numbers, you have the message right away without doing extra work.

Do you ever wonder why errno is number and not error string ?


You really should listen to Daniel Berlin if you ever want this to be 
officially

part of the dwarf2 standard.  Remember he is part of the committee there.


Well, I've hunch that if he has to cast vote then he will do it based on 
technical
merits and he will not cast vote based on his or someone else's initial 
position.


-
Devang

Re: [RFC] Optimization Diary

[Andrew Pinski]

On Jun 7, 2006, at 10:10 AM, Devang Patel wrote:

Is it constructive (and appropriate? but hey I'm DWARF newbie  
myself) to declare

DWARF standard limited and full of mistakes ?


No, I am saying that dwarf2 is supposed to be stable and adding stuff  
is not likely

going to happen that often unlike optimizations.

Read proposal again. There is one thing in proposal that allows to  
handle similar

situation for diary messages in nicer way.


What look funny instead of looking right?


Do you ever wonder why errno is number and not error string ?


And how many times new error numbers get added?  Almost never,  
compared to adding

a new optimization which can happen any time now.

Look at the problem this way, if it does not change that much often  
then yes it should

be a number, otherwise a message string is better.


Can we have standard numbers for file names now, then?

Thanks,
Andrew Pinski

Re: Thoughts about GC root sets

[Daniel Berlin]

Laurynas Biveinis wrote:
> Hi,
> 
>> There is a root list, generated by gengtype from parsing the files
>> looking for those GTY markers.
>>
>> So, if you look at ggc_mark_roots, you can see the walker that is
>> walking the root table.
>>
>> If you look in your *build* directory, and grep for ggc_root_tab, you
>> will see where the roots are.
> 
> Thanks, that's exactly what I didn't know :)

I only know this stuff from working on ggc-zone, and hacking up
gengtype/friends for copying collection :)
It was a complete mystery to me when i started as well.

> 
>> Again, these are all auto-generated from gengtype.  You can simply
>> register them with boehm once gcc starts, because the root set never
>> changes.
> 
> As far as I can understand, current GGC-ors do not simply register
> them as a additional roots - they walk them all the way down by the
> pointers and mark stuff as required during collection. Now, if I add
> the roots to Boehm's GC, this traversal and marking will be done
> internally by Boehm's GC. The question is, does GCC have any data
> structures looking like this: root -> some GC'ed memory -> some
> malloc'ed memory -> some GC'ed memory (or similar)?  Such cases should
> be OK with current GGC schemes, but Boehm's GC would be lost here.

No, because this would not be safe with the current collectors either.
One longstanding problem is that you can only mark gc'd memory from gc'd
memory, and it doesn't know to just not try to mark the malloc'd memory,
but to keep walking.
In fact, if you have gc'd memory pointing to malloc'd memory that isn't
marked with GTY ((skip)), it will attempt to walk + mark it and the
collector will crash :).

If you stare at ggc_set_mark, you'll see that the pagetable lookup for
the pages will crash if you try to ask it about non-gc'd memory. :)

This issue causes a lot of things to be placed in gc memory just because
they happen to have pointers to gc memory (basic blocks, etc), but
happens to be helpful for you. :)

Re: Thoughts about GC root sets

[Daniel Jacobowitz]

On Wed, Jun 07, 2006 at 06:57:45PM +0200, Laurynas Biveinis wrote:
> As far as I can understand, current GGC-ors do not simply register
> them as a additional roots - they walk them all the way down by the
> pointers and mark stuff as required during collection. Now, if I add
> the roots to Boehm's GC, this traversal and marking will be done
> internally by Boehm's GC. The question is, does GCC have any data
> structures looking like this: root -> some GC'ed memory -> some
> malloc'ed memory -> some GC'ed memory (or similar)?  Such cases should
> be OK with current GGC schemes,

No, it wouldn't be.  The collector would try to mark the malloced
memory, and blow up.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Optimization Diary

[Devang Patel]

Tom Tromey wrote:

Dan> It also has almost zero hope of working over multiple compiler versions,
Dan> being future proof in general, and not having other compiler vendors
Dan> fight over message number namespace.

The maintenance issue is a major one.  This document definitely needs
to address this, and not just in some theoretical way.  Otherwise,
chaos ensues.  I'm sure we've all seen the consequences here plenty of
times, enough to insist on a solution


Yes. When I update this proposal, I'll include more details. However, I
do not have extensive experience crafting such specs so any guidance
is very helpful.

One thing I am not very clear about myself in this discussion. Is 
optimization

diary a life time GNU extension ? Or Is it suitable enough to prepare a
proposal for inclusion in future DWARF version ?

-
Devang

Re: [RFC] Optimization Diary

[Devang Patel]

Tom Tromey wrote:


Devang> In the case of "dead code" we could use _msg. However, _cmd is
Devang> available to trigger some actions in tools that use this
Devang> information. If we let our imaginations run wild then for
Devang> example, lead developer towards __restrict documentation
Devang> (i.e. launch lang. standard doc in one window and open
Devang> particular page).

I agree, interconnections like the above are cool and useful.  But
this approach seems weird, because it is asking compiler maintainers
to decide whether a given result is a message or an action.

I think it would be more natural for the compiler to say what did or
did not happen, and then to have the IDE, or whatever, apply
interpretation to the record of the facts.  I.e., no message/action
distinction.
  



Since messages are represented using a number, how about using
one category bit to identify command message vs display message ?
Command message is a message where tools, reading opt diary,
take perform some actions.


-
Devang

Re: [RFC] Optimization Diary

[Devang Patel]

Andrew Pinski wrote:


On Jun 7, 2006, at 10:10 AM, Devang Patel wrote:

Is it constructive (and appropriate? but hey I'm DWARF newbie myself) 
to declare

DWARF standard limited and full of mistakes ?


No, I am saying that dwarf2 is supposed to be stable and adding stuff 
is not likely

going to happen that often unlike optimizations.
No, you said it has limitations and it is mistake to allow vendor 
extensions in DWARF.


Read proposal again. There is one thing in proposal that allows to 
handle similar

situation for diary messages in nicer way.


What look funny instead of looking right?


Optimization diary has its own version number. When new messages
are included version number is updated. This allows its consumer to
take appropriate action and not choke. Appropriate action may be, ignore
entire diary or ignore unknown messages or something else...



Do you ever wonder why errno is number and not error string ?


And how many times new error numbers get added?  Almost never, 
compared to adding

a new optimization which can happen any time now.

Look at the problem this way, if it does not change that much often 
then yes it should

be a number, otherwise a message string is better.


Can we have standard numbers for file names now, then?


OK, I opened the wrong window and this has no relation to this 
discussion. Lets close

and stay focused :)

Since you chose to not continue discuss regarding your three questions 
(overlapping

numbers, no space in extension range and tools mismatch), I guess I've
answered all your questions.

-
Devang

Re: Thoughts about GC root sets

[Laurynas Biveinis]

Hi,

Yet another question: there are several root lists: gt_ggc_rtab,
gt_ggc_deletable_rtab, gt_pch_cache_rtab, gt_pch_scalar_rtb. Now what
is what? I see that gt_ggc_rtab is an "ordinary" list. The deletable
one seems to have things that can be always collected? The names of
the last two ones suggest that they are more of a PCH interest and
disregarded as such by GGC? So I should be able to register only the
roots in the gt_ggc_rtab? (I suspect that no...)


This issue causes a lot of things to be placed in gc memory just because
they happen to have pointers to gc memory (basic blocks, etc), but
happens to be helpful for you. :)


Indeed, at least until the idea of Boehm's GC in GCC is not thrown out :)

--
Laurynas

Re: Thoughts about GC root sets

[Daniel Berlin]

Laurynas Biveinis wrote:
> Hi,
> 
> Yet another question: there are several root lists: gt_ggc_rtab,
> gt_ggc_deletable_rtab, gt_pch_cache_rtab, gt_pch_scalar_rtb. Now what
> is what? I see that gt_ggc_rtab is an "ordinary" list. The deletable
> one seems to have things that can be always collected? 

Yes.

> The names of
> the last two ones suggest that they are more of a PCH interest and
> disregarded as such by GGC? So I should be able to register only the
> roots in the gt_ggc_rtab? (I suspect that no...)

you will also have to mark the stringpool, and probably process the
cache rtabs like ggc_mark_roots does, though theoretically you should be
able to get away with not processing the cache rtabs.

Re: [RFC] Optimization Diary

[Andrew Pinski]

> No, you said it has limitations and it is mistake to allow vendor 
> extensions in DWARF.
My exact words were:
Not my fault and not really related because we are creating a new standard and
don't want to repeat this mistake, messages don't have this issue.

I was not trying to imply dwarf2 was mistaken to use numbers.


> >
> >> Read proposal again. There is one thing in proposal that allows to 
> >> handle similar
> >> situation for diary messages in nicer way.
> >
> > What look funny instead of looking right?
> 
> Optimization diary has its own version number. When new messages
> are included version number is updated. This allows its consumer to
> take appropriate action and not choke. Appropriate action may be, ignore
> entire diary or ignore unknown messages or something else...

Version numbers are sometimes counter productive.

So you don't want stuff for free fine, then go implement what ever you want
with out thinking about adding new optimziations.

> >
> >> Do you ever wonder why errno is number and not error string ?
> >
> > And how many times new error numbers get added?  Almost never, 
> > compared to adding
> > a new optimization which can happen any time now.
> >
> > Look at the problem this way, if it does not change that much often 
> > then yes it should
> > be a number, otherwise a message string is better.
> >
> >
> > Can we have standard numbers for file names now, then?
> 
> OK, I opened the wrong window and this has no relation to this 
> discussion. Lets close and stay focused :)

How is it not related, you asked about error numbers staying the same
and I just mention they are not changing that often, even dwarf2 does not
change that often.

> Since you chose to not continue discuss regarding your three questions 
> (overlapping
> numbers, no space in extension range and tools mismatch), I guess I've
> answered all your questions.

Overlapping numbers and tool mismatch are instaintly solved with messages
and there is no problems with space in the extension range because you don't
need a range.

The other issue that numbers come with is are the corresponding messages
sharable between compilers and compiler versions?

Like say, call location was not inlined because number of times this function
can be inlined was hit.  Shouldn't we provide this information to the user 
instead
of saying it was not inlined (with no reason).  Yes this is extension range but
what happens when two compilers says the same thing but a third cannot say that 
but
instead says "because 10 inlines is too much for the function".


Or with the vectorizer in mind, we have to version this loop for alignment 
because
we can only prove the alignment is 4 bytes.  Isn't that better than just saying 
the
loop was version because alignment cannot be proved to be 16bytes?

-- Pinski

Re: [RFC] Optimization Diary

[Devang Patel]

Andrew Pinski wrote:
No, you said it has limitations and it is mistake to allow vendor 
extensions in DWARF.


My exact words were:
Not my fault and not really related because we are creating a new standard and
don't want to repeat this mistake, messages don't have this issue.

I was not trying to imply dwarf2 was mistaken to use numbers.
  


"... don't want to repeat **this** mistake ...". What are referring here ?

Read proposal again. There is one thing in proposal that allows to 
handle similar

situation for diary messages in nicer way.


What look funny instead of looking right?
  

Optimization diary has its own version number. When new messages
are included version number is updated. This allows its consumer to
take appropriate action and not choke. Appropriate action may be, ignore
entire diary or ignore unknown messages or something else...



Version numbers are sometimes counter productive.
  


How ?

Since you chose to not continue discuss regarding your three questions 
(overlapping

numbers, no space in extension range and tools mismatch), I guess I've
answered all your questions.




Overlapping numbers and tool mismatch are instaintly solved with messages
and there is no problems with space in the extension range because you don't
need a range.
  


And string does not answer localization issue, however for numbers at least
there is one precedent to follow.

The other issue that numbers come with is are the corresponding messages
sharable between compilers and compiler versions?
  


Again it is a not a unsolvable issue.

Plus strings do not play nice with command messages.


Like say, call location was not inlined because number of times this function
can be inlined was hit.  Shouldn't we provide this information to the user 
instead
of saying it was not inlined (with no reason).  Yes this is extension range but
what happens when two compilers says the same thing but a third cannot say that 
but
instead says "because 10 inlines is too much for the function".
  


So ? What are you trying to say here ?


Or with the vectorizer in mind, we have to version this loop for alignment 
because
we can only prove the alignment is 4 bytes.  Isn't that better than just saying 
the
loop was version because alignment cannot be proved to be 16bytes?
  


So, what are you trying to say here ?

-
Devang

Re: [RFC] Optimization Diary

[Daniel Jacobowitz]

On Wed, Jun 07, 2006 at 11:29:44AM -0700, Devang Patel wrote:
> And string does not answer localization issue, however for numbers at least
> there is one precedent to follow.

I think this discussion has gotten totally sidetracked.  When I said
I was in favor of strings, I didn't mean messages that would ever be
displayed!  It's the difference between DW_TAG_compile_unit and
"compile-unit".

It is no more work for the producer or for the consumer, it's clearer,
and conflicts are much less likely.  The only downside is that it's
larger.  But with string duplicate elimination - your linker can
do that, I hope - it's only larger by a trivial amount.


-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Optimization Diary

[Andrew Pinski]

> 
> And string does not answer localization issue, however for numbers at least
> there is one precedent to follow.

And strings have precedent for localization also, just look into how
GCC's error messages are done.  Or even any of the Mac OS X programs
which does all localization based on strings.  I don't see this as a problem.

> > The other issue that numbers come with is are the corresponding messages
> > sharable between compilers and compiler versions?
> >   
> 
> Again it is a not a unsolvable issue.
> 
> Plus strings do not play nice with command messages.

What do you mean by play nice.  variable names play nice so it has to play nice 
already

> 
> > Like say, call location was not inlined because number of times this 
> > function
> > can be inlined was hit.  Shouldn't we provide this information to the user 
> > instead
> > of saying it was not inlined (with no reason).  Yes this is extension range 
> > but
> > what happens when two compilers says the same thing but a third cannot say 
> > that but
> > instead says "because 10 inlines is too much for the function".
> >   
> 
> So ? What are you trying to say here ?

That we cannot make a set of numbers that match up every single possibility that
could exist even currently.


> >
> > Or with the vectorizer in mind, we have to version this loop for alignment 
> > because
> > we can only prove the alignment is 4 bytes.  Isn't that better than just 
> > saying the
> > loop was version because alignment cannot be proved to be 16bytes?
> >   
> 
> So, what are you trying to say here ?

Likewise, I was trying to give an example of why numbers just fail.

-- Pinski

Re: [RFC] Optimization Diary

[Devang Patel]

Daniel Jacobowitz wrote:

On Wed, Jun 07, 2006 at 11:29:44AM -0700, Devang Patel wrote:
  

And string does not answer localization issue, however for numbers at least
there is one precedent to follow.



I think this discussion has gotten totally sidetracked.  


I agree.

When I said
I was in favor of strings, I didn't mean messages that would ever be
displayed!  It's the difference between DW_TAG_compile_unit and
"compile-unit".

It is no more work for the producer or for the consumer, it's clearer,
and conflicts are much less likely.  The only downside is that it's
larger.  But with string duplicate elimination - your linker can
do that, I hope - it's only larger by a trivial amount.
  


I am not too tied with initial positions of this proposal (see my
discussions with Tom) however in this case trade offs are not
favoring one or other with wide margin. Plus if you see my last
message to Tom in this thread, we are talking about using
_msg to say  "highlight this text". I think it makes more sense
to not use strings in this situation.

Anyway, time to focus discussion on other open questions.

1) Steven B. off line suggested that we need some mechanism to
identify compiler phase. I agree, it is useful to filter messages.
What do other people think about it ?

2) Do we need to enforce source location ordering in diary messages ?

-
Devang

Re: [RFC] Optimization Diary

[Geoffrey Keating]

On 07/06/2006, at 11:33 AM, Daniel Jacobowitz wrote:


On Wed, Jun 07, 2006 at 11:29:44AM -0700, Devang Patel wrote:
And string does not answer localization issue, however for numbers  
at least

there is one precedent to follow.


I think this discussion has gotten totally sidetracked.  When I said
I was in favor of strings, I didn't mean messages that would ever be
displayed!  It's the difference between DW_TAG_compile_unit and
"compile-unit".


Apparently, "strings" means lots of different things to different  
people.  Everyone hopes that a string will solve their perceived  
problem without realising that everyone else is hoping for something  
incompatible.



It is no more work for the producer or for the consumer, it's clearer,
and conflicts are much less likely.  The only downside is that it's
larger.  But with string duplicate elimination - your linker can
do that, I hope - it's only larger by a trivial amount.


It's important to realise that when we complain about debug size, we  
mean in .o files.  Our linker doesn't copy any DWARF debug  
information to its product.

smime.p7s
Description: S/MIME cryptographic signature

Re: [RFC] Optimization Diary

[Tom Tromey]

> "Devang" == Devang Patel <[EMAIL PROTECTED]> writes:

Devang> Since messages are represented using a number, how about using
Devang> one category bit to identify command message vs display message ?
Devang> Command message is a message where tools, reading opt diary,
Devang> take perform some actions.

I still don't see how gcc maintainers would know to make this
distinction.  Perhaps I'm misunderstanding the distinction between
command and display.

Tom

Re: [RFC] Optimization Diary

[Devang Patel]

Tom Tromey wrote:

"Devang" == Devang Patel <[EMAIL PROTECTED]> writes:



Devang> Since messages are represented using a number, how about using
Devang> one category bit to identify command message vs display message ?
Devang> Command message is a message where tools, reading opt diary,
Devang> take perform some actions.

I still don't see how gcc maintainers would know to make this
distinction.  Perhaps I'm misunderstanding the distinction between
command and display.
  


for (i=0; i<4; i++)
{
 C[i] = A[i] + C[i+3];
}

Auto vectorizer emits three messages.
1) This loop is not vectorized because of data dependency.
2) Highlight C[i]
3) Highlight C[i+3]

Here vectorizer knows that 2) and 3) are commands and 1) is display message.

-
Devang

Re: [RFC] Optimization Diary

[Paul Brook]

> > I still don't see how gcc maintainers would know to make this
> > distinction.  Perhaps I'm misunderstanding the distinction between
> > command and display.
>
> for (i=0; i<4; i++)
> {
>   C[i] = A[i] + C[i+3];
> }
>
> Auto vectorizer emits three messages.
> 1) This loop is not vectorized because of data dependency.
> 2) Highlight C[i]
> 3) Highlight C[i+3]
>
> Here vectorizer knows that 2) and 3) are commands and 1) is display
> message.

I don't buy this. Whether things are highlighted or comments added seems like 
something that the consumer should decide. ie. the compiler generates:

1) {points at for loop} Loop not vectorized because of data dependency
1a) {points at C[i]} Conflicting data element
1b) {points at C[i+3]} Conflicting data element

Paul

g++ compiler enhancement request

[lkeren]

Hi,

I'm a Msc. student in the computer science department of the Technion, the
Israeli Institute of Technology.
My thesis is on compile time checking of dynamic SQL queries using C++
templates.
There is a __COUNTER__ macro, supported by Microsoft C++ compiler which can
help
me a lot in the thesis implementation.
This macro expands to an integer starting with 0 and incrementing by 1 every
time it is used.
I believe it is a very useful macro way beyond my thesis.
I also think it is very simple to implement and I'm willing to implement it for
the gnu compiler.
Would you consider it adding it to the official gnu compiler if I'll implement
it?
What is the standard procedure to do so?

Thanks,
Keren.

Re: g++ compiler enhancement request

[Ian Lance Taylor]

[EMAIL PROTECTED] writes:

> I'm a Msc. student in the computer science department of the Technion, the
> Israeli Institute of Technology.
> My thesis is on compile time checking of dynamic SQL queries using C++
> templates.
> There is a __COUNTER__ macro, supported by Microsoft C++ compiler which can
> help
> me a lot in the thesis implementation.
> This macro expands to an integer starting with 0 and incrementing by 1 every
> time it is used.
> I believe it is a very useful macro way beyond my thesis.
> I also think it is very simple to implement and I'm willing to implement it 
> for
> the gnu compiler.
> Would you consider it adding it to the official gnu compiler if I'll implement
> it?

Yes, we would consider it.

> What is the standard procedure to do so?

Short version: Sign a copyright assignment so that we can use your
code.  Write the patch.  Test the patch.  Send the patch to
[EMAIL PROTECTED]

Long version: http://gcc.gnu.org/contribute.html

Thanks for your interest.

Ian

Re: g++ compiler enhancement request

[Steven Bosscher]

On 6/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Hi,

I'm a Msc. student in the computer science department of the Technion, the
Israeli Institute of Technology.
My thesis is on compile time checking of dynamic SQL queries using C++
templates.
There is a __COUNTER__ macro, supported by Microsoft C++ compiler which can
help
me a lot in the thesis implementation.
This macro expands to an integer starting with 0 and incrementing by 1 every
time it is used.
I believe it is a very useful macro way beyond my thesis.
I also think it is very simple to implement and I'm willing to implement it for
the gnu compiler.
Would you consider it adding it to the official gnu compiler if I'll implement
it?
What is the standard procedure to do so?


First of all, you would have to define exactly how this __COUNTER__
macro would behave (for example, what does it do in a template
context? when is the counter incremented?).

Then, you'd have to file a copyright assignment because the gcc
project only accepts patches if the copyright is assigned to the FSF.
Finally, you'd write and submit the patch.

Simple enough, no? :-)

Gr.
Steven

RE: RFC: x86 Linux stack alignment requirement

[Menezes, Evandro]

> There are 2 different, but related questions:
> 
> 1. Should Linux require gcc generates 16byte aligned stack?
> 2. How should Linux support 4byte alignment code?

Independently of Linux, GCC could align the stack at 16 bytes and still be 
compliant with the psABI.  It could also wrap memalign as malloc...

-- 
___
Evandro Menezes   AMDAustin, TX

RE: x86 Linux stack alignment requirement

[Menezes, Evandro]

HJ, 

> We have several choices for stack alignment requirement
> 
> 1. Leave it unchanged. Gcc can do
>   a. Nothing. Let the program crash.
>   b. Align stack to 16byte if XMM registers are used locally and
>aren't passed down as function arguments.

Why not so if the XMM registers are passed down as arguments?

Thanks,

-- 
___
Evandro Menezes   AMDAustin, TX

Re: x86 Linux stack alignment requirement

[H. J. Lu]

On Wed, Jun 07, 2006 at 04:08:14PM -0500, Menezes, Evandro wrote:
> HJ, 
> 
> > We have several choices for stack alignment requirement
> > 
> > 1. Leave it unchanged. Gcc can do
> > a. Nothing. Let the program crash.
> > b. Align stack to 16byte if XMM registers are used locally and
> >aren't passed down as function arguments.
> 
> Why not so if the XMM registers are passed down as arguments?
> 

When calling a function with XMM register arguments, doesn't caller
have to align stack to 16byte for callee?


H.J.

Re: g++ compiler enhancement request

[Perry Smith]

You might also check boost.org to see if they have this concept  
already implemented.  And if not, you could contribute it to them as  
well.


On Jun 7, 2006, at 3:17 PM, [EMAIL PROTECTED] wrote:


Hi,

I'm a Msc. student in the computer science department of the  
Technion, the

Israeli Institute of Technology.
My thesis is on compile time checking of dynamic SQL queries using C++
templates.
There is a __COUNTER__ macro, supported by Microsoft C++ compiler  
which can

help
me a lot in the thesis implementation.
This macro expands to an integer starting with 0 and incrementing  
by 1 every

time it is used.
I believe it is a very useful macro way beyond my thesis.
I also think it is very simple to implement and I'm willing to  
implement it for

the gnu compiler.
Would you consider it adding it to the official gnu compiler if  
I'll implement

it?
What is the standard procedure to do so?

Thanks,
Keren.

RE: x86 Linux stack alignment requirement

[Menezes, Evandro]

> > > We have several choices for stack alignment requirement
> > > 
> > > 1. Leave it unchanged. Gcc can do
> > >   a. Nothing. Let the program crash.
> > >   b. Align stack to 16byte if XMM registers are used locally and
> > >aren't passed down as function arguments.
> > 
> > Why not so if the XMM registers are passed down as arguments?
> 
> When calling a function with XMM register arguments, doesn't caller
> have to align stack to 16byte for callee?

Not necessarily, I think.  Just like the caller aligned its stack to 16 bytes, 
the callee can do the same while still assuming the 4-byte alignment.  And it's 
an even lesser problem with -msseregparm or the sseregparam attribute.

-- 
___
Evandro Menezes   AMDAustin, TX

Re: x86 Linux stack alignment requirement

[H. J. Lu]

On Wed, Jun 07, 2006 at 05:17:39PM -0500, Menezes, Evandro wrote:
> > > > We have several choices for stack alignment requirement
> > > > 
> > > > 1. Leave it unchanged. Gcc can do
> > > > a. Nothing. Let the program crash.
> > > > b. Align stack to 16byte if XMM registers are used locally and
> > > >aren't passed down as function arguments.
> > > 
> > > Why not so if the XMM registers are passed down as arguments?
> > 
> > When calling a function with XMM register arguments, doesn't caller
> > have to align stack to 16byte for callee?
> 
> Not necessarily, I think.  Just like the caller aligned its stack to 16 
> bytes, the callee can do the same while still assuming the 4-byte alignment.  
> And it's an even lesser problem with -msseregparm or the sseregparam 
> attribute.

How are XMM arguments passed by default? What happens when there are
more 16 XMM parameters?

Is XMM supported with variable argument list? 


H.J.

RE: x86 Linux stack alignment requirement

[Menezes, Evandro]

> > > > > We have several choices for stack alignment requirement
> > > > > 
> > > > > 1. Leave it unchanged. Gcc can do
> > > > >   a. Nothing. Let the program crash.
> > > > >   b. Align stack to 16byte if XMM registers are 
> used locally and
> > > > >aren't passed down as function arguments.
> > > > 
> > > > Why not so if the XMM registers are passed down as arguments?
> > > 
> > > When calling a function with XMM register arguments, 
> doesn't caller
> > > have to align stack to 16byte for callee?
> > 
> > Not necessarily, I think.  Just like the caller aligned its 
> stack to 16 bytes, the callee can do the same while still 
> assuming the 4-byte alignment.  And it's an even lesser 
> problem with -msseregparm or the sseregparam attribute.
> 
> How are XMM arguments passed by default? What happens when there are
> more 16 XMM parameters?
> Is XMM supported with variable argument list? 

I see.  Provided a local is passed in a register to a non-vararg function, it 
is still OK to align the stack.

-- 
___
Evandro Menezes   AMDAustin, TX

Re: apply for the relevant forms

[Jie Zhang]

On 6/5/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Our Co. have a new 32b embedded processor, and we have ported the gcc
backend for it(support c/c++), now we want add its backend code into gcc
packages. i read the "Contributing to GCC " pages that we must sign some
forms, can you kindly send the forms to me?


It said on :  "It's a good idea to
send [EMAIL PROTECTED] a copy of your request.", not gcc mailing
list.

And [EMAIL PROTECTED] and gcc@gcc.gnu.org are same thing, no need to send to 
both.

Jie

apply for the relevant forms

[liqin]

Our Co. have a new 32 bit embedded processor, and we have ported the gcc 
backend for it(support c/c++), now we want add its backend code into gcc 
packages. i read the "Contributing to GCC " pages that we must sign some 
forms, can you kindly send the forms to me?

Best Regards
Liqin

-mno-80387 and MMX autovectorisation

[Uros Bizjak]

Hello!

Current mainline gcc can efficiently disable x87 instruction when
-mno-80387 switch is used. In this case, MMX registers can be used for
the autovectorisation even without emms or femms instructions to
switch back to x87 mode.

-mno-80387 introduces ABI change, so existing libraries are already
incompatible with -mno-80387 compiled programs.

Attached RFC patch shows the condition to enable MMX vectorisation. To
generate MMX instructions, a bunch of patterns in mmx.md has also to
be renamed, as shown in the patch of PR target/14559. The benefits of
this approach is the usage of another set otherwise idle 128bit
registers in addition to existing SSE regs. Also, integer
vectorisation could be easily enabled for (embedded) MMX processors.

Uros.


mmx.diff
Description: Binary data