[plugins] Re: comparison of plugin mechanisms
Hello everybody, 2009/2/13 Basile STARYNKEVITCH wrote >Hello All, > >I am not sure of the relevance of the "new pass integration plugins" > examplified by MELT. >[...] >In my view, MELT fits quite precisely in the "production plugins" > definition, while indeed I expect it to be useful mostly for > "experimental/research" plugins. > >In my view also, the "new pass integration plugin" category should not > really exist, because it probably can fit inside one (or both) of the above > categories. >[...] >Also, I don't understand why "production plugins" or > "experimental/research plugins" could not be coded in another language than > C. For sure, they could probably be coded in a suitable subdialect of C++ at > least. The classification of plugins into the three categories was intended to illustrate the differences in API constraints; MELT is an example of multi-language programming that calls for non-C bindings in the plugin API. This is in fact orthogonal to the level of abstraction, which is the key differentiator between the "production" and the "experimentation" approaches. Efficiency is a concern in all cases, but is addressed at different levels: the idea behind the experimental part of the API is to help searching for a good/better way of dealing with a problem, while the production API should provide the means of implementing the chosen method as efficiently as possible. > I did not understood yet how exactly can Grigori's production plugin API be > used to add e.g. one plugin pass inside the pass manager. Eg how to add one > pass fooplugin_pass provided by a plugin just after the > pass_inline_parameters, or another plugin pass barplugin_pass just after > pass_ipa_struct_reorg? >I assume such things could be possible... To support "dynamic" passes (supplied by plugin), Grigori's API needs two more primitives to register and unregister new passes (plus a function to get the struct opt_pass by name for the production API). The rest of the machinery remains unchanged. The solution will be then to: * register the dynamic passes upon loading the plugin, * generate an event in execute_pass_list (say, "select_next_pass"), * modify pass chaining (or run passes directly) in the corresponding callback, based on the current position in the pass list, * unregister dynamic passes when unloading the plugin. >Regarding MELT, I believe that if a plugin facility has, in addition of > Gregori's feature, the ability to insert new dynamic passes and the ability > to add some extra GTY root & marking routine, I could fit MELT into that. If > that happens, MELT would become somehow a "metaplugin" machinery, in the > sense of a plugin which will itself load some dynamic code. Insertion of dynamic passes can be implemented very rapidly (cf. above). For GTY, maybe your patch came just too early - the motivation for it is much stronger now. Finally, the "meta-plugins" seem a natural consequence of the plugin concept itself and I expect to see more of them as soon as the plugin mechanism gains momentum in the community. All the best, Zbigniew
RE: [plugins] Comparison of plugin mechanisms
Hi Basile et al, Thanks a lot for detailed explanations. In addition to Zbigniew's reply: I didn't specifically put MELT into new category (I actually just updated the page and added it to the other categories too), but I still keep the new pass integration plugin, since some of our colleagues would like to add new passes including new optimizations, but have difficulties to do that since there is no full documented API, they may not want to write it in C (as you mentioned) and they are concerned about support overheads if the internal API will be changing all the time. Providing standard API would be of great help for such cases, but it rises other issues such as opening GCC to proprietary plugins, etc which has been heavily discussed here for some time. So I personally think we should leave it for the future and just implement minimalistic Plugin API that will already make many current and prospective users happy and then we can gradually extend it ... By the way, Sean, what do you think about the proposed APIs? Will it suit your purposes or some changes are also required? I would like to add info about your plugin system but just don't have much knowledge about that ... Cheers, Grigori > -Original Message- > From: Basile STARYNKEVITCH [mailto:bas...@starynkevitch.net] > Sent: Friday, February 13, 2009 8:38 AM > To: Grigori Fursin > Cc: 'Diego Novillo'; gcc@gcc.gnu.org; 'Sean Callanan'; 'Taras Glek'; 'Le-Chun > Wu'; 'Gerald > Pfeifer'; 'Zbigniew Chamski'; 'Cupertino Miranda' > Subject: Re: [plugins] Comparison of plugin mechanisms > > Hello All, > > > Grigori Fursin wrote: > > Basically, we currently see 3 complementary categories of GCC plugins, > > depending > > on the nature of the extension: production, experimentation/research, and > > new pass > > integration. Each category naturally calls for slightly different API > > features. > > > > > I am not sure of the relevance of the "new pass integration plugins" > examplified by MELT. > [on the other hand, I do know Grigori and I believe he thought quite a > lot about plugins, which I didn't. I only implemented one particular > plugin machinery = MELT, knowing well that my approach is quite peculiar > both in its goals and its implementation. I never thought of MELT as a > universal plugin machinery). > > In my view, MELT fits quite precisely in the "production plugins" > definition, while indeed I expect it to be useful mostly for > "experimental/research" plugins. > > In my view also, the "new pass integration plugin" category should not > really exist, because it probably can fit inside one (or both) of the > above categories. > > MELT definitely claims to fit into the "production plugins" slot, > because MELT always was concerned by efficiency and most importantly > close integration of GCC internal structures. The major point of MELT > is its several idioms to fit into the *evolving* GCC internals API, > and I claim that the various MELT idioms (see my GROW paper) make > close integration into GCC internals possible, and perhaps even easy > (for each internal "feature" of GCC, it is really easy to code the > couple of MELT line to use it). > > Of course, MELT is mostly motivated by "experimental/research plugins", > in the sense that MELT will be mostly useful for experimental and > prototyping. I never thought that MELT would be useful for coding > definitive optimisation passes, but it should be useful to at least > prototype them. Actually, I really believe that for ordinary > optimisation, any plugin machinery is not used. In other words, I tend > to think that even in -O3 (or a future -O4) no plugin will be dlopen-ed > by default in GCC. [by the way, I believe that this last fact is > unfortunate; I would like plugins to be routinely used inside GCC, but I > do know that most of the GCC community disagree.] > > Also, I don't understand why "production plugins" or > "experimental/research plugins" could not be coded in another language > than C. For sure, they could probably be coded in a suitable subdialect > of C++ at least. > > I do like Grigori's plugin API proposal. (but again, I definitely do not > claim to be a plugin theorist, only a particular plugin implementor, > with MELT having specific needs & solutions.). > > I did not understood yet how exactly can Grigori's production plugin API > be used to add e.g. one plugin pass inside the pass manager. Eg how to > add one pass fooplugin_pass provided by a plugin just after the > pass_inline_parameters, or another plugin pass barplugin_pass just after > pass_ipa_struct_reorg? > I assume such things could be possible... > > There is another issue which has not been discussed enough in my view. > The interaction between some GCC plugins and the GGC memory > manager/garbage collector. More precisely: > > 1. How can a plugin fooplugin.c use GTY() notation, and therefore > generate a gt-fooplugin.h which is #include-d at the end of fooplugin.c? > conceptua
About strict-aliasing warning
hi all,
I wrote a simple testcase with some type prunned pointer and
compiled it with -O2 option.
I assumed that gcc would issue some warnings as told in its documents.
But i am afraid that no warnings at all. I have to specify the
-Wstrict-aliasing or -Wall option manually.
Is this a document inconsistency or a little bug, or what else I
should pay attention to before doing the test?
I have tried differenct version of gcc in Ubuntu 8.04/8.10, none
warnings for gcc-3.3/3.4/4.2/4.3 .
In GCC's documents(http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html)
"-Wstrict-aliasing
This option is only active when -fstrict-aliasing is active. It
warns about code which might
break the strict aliasing rules that the compiler is using for
optimization. The warning does
not catch all cases, but does attempt to catch the more common
pitfalls. It is included in -Wall.
It is equivalent to -Wstrict-aliasing=3 "
and -O2 would active -fstrict-aliasing by default, which should also
active this options.
BTW: the simple testcase:
1 #include
2
3 int main()
4 {
5 int a = 0x12345678;
6 short *p = (short *)&a;
7 short temp;
8 temp = *p;
9 *p = *(p+1);
10 *(p+1) = temp;
11 printf("%x\n", a);
12 }
Thanks.
Best,
Jim
Re: About strict-aliasing warning
> "-Wstrict-aliasing > This option is only active when -fstrict-aliasing is active. It > warns about code which might > break the strict aliasing rules that the compiler is using for > optimization. The warning does > not catch all cases, but does attempt to catch the more common > pitfalls. It is included in -Wall. > It is equivalent to -Wstrict-aliasing=3 " > > and -O2 would active -fstrict-aliasing by default, which should also > active this options. No, the text above means that "-fstrict-aliasing" is a *necessary* condition to get aliasing warnings, not a sufficient condition. Do you have suggestions for how to clarify the text? Paolo
Re: About strict-aliasing warning
Paolo Bonzini wrote: "-Wstrict-aliasing This option is only active when -fstrict-aliasing is active. It warns about code which might break the strict aliasing rules that the compiler is using for optimization. The warning does not catch all cases, but does attempt to catch the more common pitfalls. It is included in -Wall. It is equivalent to -Wstrict-aliasing=3 " and -O2 would active -fstrict-aliasing by default, which should also active this options. No, the text above means that "-fstrict-aliasing" is a *necessary* condition to get aliasing warnings, not a sufficient condition. Do you have suggestions for how to clarify the text? Pergaps the first sentence should read something like "This option is only respected when -fstrict-aliasing is active", or "This option has no effect unless -fstrict-aliasing is active". I follow what the existing wording was intended to mean, but I can also see how it could easily be interpreted to mean that -fstrict-aliasing automatically implies -Wstrict-aliasing. -- Ross Smith
IRA conflict graph & alternative selection
I've been thinking further about instruction alternative selection prior to allocation and one of the questions in my mind is how this interacts with IRA. We select an alternative for each insn based on some "best guess" heuristic -- the selection of an alternative will often restrict the register classes available for each of the operands. Presumably we'd want to encode that information it the conflict graph so that IRA would allocate registers so as to fit the constraints of the early insn alternative selection. Right? In the case where the graph is uncolorable, do we allow IRA to override the alternative selection, or do we insert copies to simplify the conflict graph or some mixture of both? Thoughts? jeff
Re: IRA conflict graph & alternative selection
Jeff Law wrote: > We'd want to encode [early insn alternative selection] > information in the conflict graph so that IRA would > allocate registers so as to fit the constraints of the early insn > alternative selection. Right? In the case where the graph is > uncolorable, do we allow IRA to override the alternative selection, or > do we insert copies to simplify the conflict graph or some mixture of both? Inserting compensation code, for example copies, can be seen as some kind of "pre-reload" as it was used on new-ra branch; the problem with pre-reload was that it was built on "cp reload1.c pre-reload.c", so it was not much less complicated than reload. Paolo
Re: IRA conflict graph & alternative selection
Hi, On Fri, 13 Feb 2009, Paolo Bonzini wrote: > > We'd want to encode [early insn alternative selection] information in > > the conflict graph so that IRA would allocate registers so as to fit > > the constraints of the early insn alternative selection. Right? In > > the case where the graph is uncolorable, do we allow IRA to override > > the alternative selection, or do we insert copies to simplify the > > conflict graph or some mixture of both? If the initial alternative selection was done cleverly (like chose the alternatives allowing the largest register sets which don't immediately create conflicting demands for a pseudo register) the opportunities for making an uncolorable graph colorable by chosing another alternative will be very small. This can only happen if that new alternative somehow allows for the uncolorable node a completely new set of register (like say float instead of integer regs), which would mean also selecting other alternatives for all instructions where this pseudo also is used. So it's not impossible, but I think it would happen relatively seldom that changing the alternatives improves the situation. > Inserting compensation code, for example copies, can be seen as some > kind of "pre-reload" as it was used on new-ra branch; the problem with > pre-reload was that it was built on "cp reload1.c pre-reload.c", so it > was not much less complicated than reload. Unnecessarily so, though. Faster to have something working, but as the problem is much easier (and you still can reasonably create new pseudos) also the solution can be. It just never was followed through. Ciao, Michael.
Re: IRA conflict graph & alternative selection
Jeff Law wrote: I've been thinking further about instruction alternative selection prior to allocation and one of the questions in my mind is how this interacts with IRA. We select an alternative for each insn based on some "best guess" heuristic -- the selection of an alternative will often restrict the register classes available for each of the operands. Presumably we'd want to encode that information it the conflict graph so that IRA would allocate registers so as to fit the constraints of the early insn alternative selection. Right? In the case where the graph is uncolorable, do we allow IRA to override the alternative selection, or do we insert copies to simplify the conflict graph or some mixture of both? Thoughts? Sticking with one insn alternative (by alternative I mean set of operand constraints - one constraint for one operand. That is different from RTL insn alternative which is superset of such set) permits more accurate (and much faster) cost calculation of register class costs for pseudos which improves coloring and spilling decisions especially for CISC architectures likes x86, x86_64. On the other hand it rejects some more possible alternatives. What is more important? I don't know. Therefore I wrote about it as an experiment. That is ok because to get current state IRA algorithms I tried probably 5 times more different coloring algorithms. As for copies, I think it would be a bad decision to stick only to original (after the code selection) alternative and generate copies to satisfy this alternative. For example, if pseudo got memory instead of hard-register required by the alternative, it would be bad to generate a copy (ld/st in this case) if memory is accepted by the insn. That is because a new pseudo will need a hard register and could result in spilling another pseudo. And this can not be fixed by a simple subsequent pass removing ld/st by using memory operands. So I think if the altrernative is not satisfied then we should choose the cheapest one and use it for the insn. Still some copies might be needed to satisfy the new alternative. After changing some insn alternatives and generating copies, choosing alternative for them and generating new pseudos we modify register class costs of the pseudos and calculate costs for the new pseudos (it should be a fast process because we need to change costs only for pseudos involved in insns with changed alternatives and because again each insn has only one alternative). After cost recalculation, another round of coloring is done. That is in brief how I see it and there are a lot of reload details missed (like virtual register eliminations or addressing displacement constraints etc).
Re: IRA conflict graph & alternative selection
> As for copies, I think it would be a bad decision to stick only to > original (after the code selection) alternative and generate copies to > satisfy this alternative. For example, if pseudo got memory instead of > hard-register required by the alternative, it would be bad to generate a > copy (ld/st in this case) if memory is accepted by the insn. Yes, spilling is a special case (see also PR19398). If something is spilled, "prereloads" could be rolled back for affected instructions and recomputed (possibly forcing no change on the constraints of other registers). > That is in brief how I see it and there are a lot of reload details > missed (like virtual register eliminations or addressing displacement > constraints etc). I suppose those would stay in reload? Michael, what were your intentions for the insn-sel branch? (Sorry to remind you of that :-P). Paolo
Incomplete Type on Pass By Value bug in g++ <4.3.0
I asked on gcc-help, but it seems like this list may be more
appropriate as it deals with the gcc source.
I have noticed that in my g++ <4.3.0, I am able to compile the
following code without any errors:
struct A;
void foo(A);
void bar(A* p){foo(*p);}
In g++ 4.3.0 this seems to have been fixed, but I'm having a very hard
time locating the fix for it. I was hoping that someone could point me
in a general direction and hopefully even a changeset. I would like to
be able to backport this to g++ 4.1.2 if possible.
Thank you,
Anthony
Re: IRA conflict graph & alternative selection
Paolo Bonzini wrote: Jeff Law wrote: We'd want to encode [early insn alternative selection] information in the conflict graph so that IRA would allocate registers so as to fit the constraints of the early insn alternative selection. Right? In the case where the graph is uncolorable, do we allow IRA to override the alternative selection, or do we insert copies to simplify the conflict graph or some mixture of both? Inserting compensation code, for example copies, can be seen as some kind of "pre-reload" as it was used on new-ra branch; It can certainly be viewed that way; however, it helps me to think in terms of having IRA generate spill code. The difference is subtle, but it's helping me get away from the reload-centric mindset which keeps creeping in. the problem with pre-reload was that it was built on "cp reload1.c pre-reload.c", so it was not much less complicated than reload. Precisely. And I'm finding that as I look at the existing reload code and ponder where/how to do things better I always end up with the same code, but just at a different place in the pipeline. That shouldn't be the goal here -- the goal should be something more maintainable and predictable than reload. What I think I'm getting at is we should be looking at common reload cases and mapping them into changes to the conflict graph within IRA (possibly with some copies inserted as compensation code). Jeff
Does gcc conform to C++ ABI?
Hi,
It may be a known issue. Does gcc follow Section 5.1.6 Scope Encoding
in C++ ABI:
http://www.codesourcery.com/public/cxx-abi/abi.html#mangling
I tried the example. But it won't compile. I changed it to:
[...@gnu-6 tmp]$ cat x.cc
namespace N {
inline char f(int i) {
static const char *p = "Itanium C++ ABI"; // p = 1, "..." = 2
{ struct X { // X = 3
void g() {}
}; }
return p[i];
}
char
foo (int i)
{
return f (i);
}
}
[...@gnu-6 tmp]$ gcc -c x.cc
[...@gnu-6 tmp]$ nm x.o
W _ZN1N1fEi
T _ZN1N3fooEi
V _ZZN1N1fEiE1p
U __gxx_personality_v0
[...@gnu-6 tmp]$ nm x.o | c++filt
W N::f(int)
T N::foo(int)
V N::f(int)::p
U __gxx_personality_v0
[...@gnu-6 tmp]$
It doesn't
"_ZZN1N1fEiEs": encoding of N::f::"Itanium C++ ABI" (no discriminator)
--
H.J.
Re: Incomplete Type on Pass By Value bug in g++ <4.3.0
On Fri, Feb 13, 2009 at 08:53:34AM -0800, Anthony Newnam wrote:
> I asked on gcc-help, but it seems like this list may be more
> appropriate as it deals with the gcc source.
>
> I have noticed that in my g++ <4.3.0, I am able to compile the
> following code without any errors:
> struct A;
> void foo(A);
> void bar(A* p){foo(*p);}
>
> In g++ 4.3.0 this seems to have been fixed, but I'm having a very hard
> time locating the fix for it. I was hoping that someone could point me
> in a general direction and hopefully even a changeset. I would like to
> be able to backport this to g++ 4.1.2 if possible.
It's possible that no one can answer you because this was fixed as a
side effect of fixing a different problem.
You might have to resort to a binary search through the subversion
database to find the fix. There's a script in the contrib area of
the gcc sources called reg_search that can help to automate the
process. The endpoints for your search would be the point where
the 4.2 branch was created, and the point where the 4.3 branch was
created, since the fix must have gone into the trunk sometime between
those two points.
Re: IRA conflict graph & alternative selection
Paolo Bonzini writes: >> That is in brief how I see it and there are a lot of reload details >> missed (like virtual register eliminations or addressing displacement >> constraints etc). > > I suppose those would stay in reload? I see no reason for those to stay in reload (especially since I think reload should disappear entirely). It is reasonable to pick the total maximum size of the stack frame, and thus resolve all displacement constraints, before register allocation. Carefully relaxing these constraints during reload can give you slightly better results for some instructions, but only in very very few cases, and only in functions which already have unusually large stack frames. I don't consider that to be an important optimization. Given that, we can determine the maximum offset for all virtual registers before register allocation, which suffices for selection of insn constraint alternatives, and then determine the actual offset, once, after register allocation. Ian
Re: Incomplete Type on Pass By Value bug in g++ <4.3.0
Thanks Joe.
As far as I know the problem I'm seeing isn't a regression but perhaps
this script could still be useful. I don't really understand how it is
supposed to work, since it doesn't appear be working off svn updates.
Should I do something like a binary svn search between revisions
124707 and 132947? It takes such a long amount of time to compile g++,
almost a half an hour with my quad core, that it didn't seem practical
try to do build so many times. I guess there is probably a way to
build g++ without the rest of gcc, but I haven't seen an option for
it.
On Fri, Feb 13, 2009 at 11:22 AM, Joe Buck wrote:
> On Fri, Feb 13, 2009 at 08:53:34AM -0800, Anthony Newnam wrote:
>> I asked on gcc-help, but it seems like this list may be more
>> appropriate as it deals with the gcc source.
>>
>> I have noticed that in my g++ <4.3.0, I am able to compile the
>> following code without any errors:
>> struct A;
>> void foo(A);
>> void bar(A* p){foo(*p);}
>>
>> In g++ 4.3.0 this seems to have been fixed, but I'm having a very hard
>> time locating the fix for it. I was hoping that someone could point me
>> in a general direction and hopefully even a changeset. I would like to
>> be able to backport this to g++ 4.1.2 if possible.
>
> It's possible that no one can answer you because this was fixed as a
> side effect of fixing a different problem.
>
> You might have to resort to a binary search through the subversion
> database to find the fix. There's a script in the contrib area of
> the gcc sources called reg_search that can help to automate the
> process. The endpoints for your search would be the point where
> the 4.2 branch was created, and the point where the 4.3 branch was
> created, since the fix must have gone into the trunk sometime between
> those two points.
>
>
>
Re: Does gcc conform to C++ ABI?
"H.J. Lu" writes:
> It may be a known issue. Does gcc follow Section 5.1.6 Scope Encoding
> in C++ ABI:
>
> http://www.codesourcery.com/public/cxx-abi/abi.html#mangling
>
> I tried the example. But it won't compile. I changed it to:
>
> [...@gnu-6 tmp]$ cat x.cc
> namespace N {
> inline char f(int i) {
> static const char *p = "Itanium C++ ABI"; // p = 1, "..." = 2
> { struct X { // X = 3
>void g() {}
> }; }
> return p[i];
> }
> char
> foo (int i)
> {
> return f (i);
> }
>}
> [...@gnu-6 tmp]$ gcc -c x.cc
> [...@gnu-6 tmp]$ nm x.o
> W _ZN1N1fEi
> T _ZN1N3fooEi
> V _ZZN1N1fEiE1p
> U __gxx_personality_v0
> [...@gnu-6 tmp]$ nm x.o | c++filt
> W N::f(int)
> T N::foo(int)
> V N::f(int)::p
> U __gxx_personality_v0
> [...@gnu-6 tmp]$
>
> It doesn't
>
> "_ZZN1N1fEiEs": encoding of N::f::"Itanium C++ ABI" (no discriminator)
The discriminator is optional and is up to the discretion of the
compiler. This doesn't matter for interoperability purposes, because
such names can not be referenced from other translation units anyhow.
What do you think the symbol name should be?
Ian
Re: Incomplete Type on Pass By Value bug in g++ <4.3.0
Anthony Newnam writes: > Should I do something like a binary svn search between revisions > 124707 and 132947? It takes such a long amount of time to compile g++, > almost a half an hour with my quad core, that it didn't seem practical > try to do build so many times. I guess there is probably a way to > build g++ without the rest of gcc, but I haven't seen an option for > it. configure with --disable-bootstrap --enable-languages=c,c++. Doing a make shouldn't take anything like half an hour on a quad core. Ian
Re: Does gcc conform to C++ ABI?
On Fri, Feb 13, 2009 at 11:05 AM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> It may be a known issue. Does gcc follow Section 5.1.6 Scope Encoding
>> in C++ ABI:
>>
>> http://www.codesourcery.com/public/cxx-abi/abi.html#mangling
>>
>> I tried the example. But it won't compile. I changed it to:
>>
>> [...@gnu-6 tmp]$ cat x.cc
>> namespace N {
>> inline char f(int i) {
>> static const char *p = "Itanium C++ ABI"; // p = 1, "..." = 2
>> { struct X { // X = 3
>>void g() {}
>> }; }
>> return p[i];
>> }
>> char
>> foo (int i)
>> {
>> return f (i);
>> }
>>}
>> [...@gnu-6 tmp]$ gcc -c x.cc
>> [...@gnu-6 tmp]$ nm x.o
>> W _ZN1N1fEi
>> T _ZN1N3fooEi
>> V _ZZN1N1fEiE1p
>> U __gxx_personality_v0
>> [...@gnu-6 tmp]$ nm x.o | c++filt
>> W N::f(int)
>> T N::foo(int)
>> V N::f(int)::p
>> U __gxx_personality_v0
>> [...@gnu-6 tmp]$
>>
>> It doesn't
>>
>> "_ZZN1N1fEiEs": encoding of N::f::"Itanium C++ ABI" (no discriminator)
>
> The discriminator is optional and is up to the discretion of the
> compiler. This doesn't matter for interoperability purposes, because
> such names can not be referenced from other translation units anyhow.
If it isn't optional, tools can't depend on it. I was wondering
how useful it was.
Another issue for scope encoding. C++ ABI:
---
Occasionally entities in local scopes must be mangled too
(e.g. because inlining or template compilation causes multiple
translation units to require access to that entity).
---
seems to imply that the local symbols may have external
linkage. Am I wrong?
> What do you think the symbol name should be?
>
Isn't it specified in C++ ABI?
--
H.J.
Re: IRA conflict graph & alternative selection
Ian Lance Taylor wrote: Paolo Bonzini writes: That is in brief how I see it and there are a lot of reload details missed (like virtual register eliminations or addressing displacement constraints etc). I suppose those would stay in reload? I see no reason for those to stay in reload (especially since I think reload should disappear entirely). It is reasonable to pick the total maximum size of the stack frame, and thus resolve all displacement constraints, before register allocation. Carefully relaxing these constraints during reload can give you slightly better results for some instructions, but only in very very few cases, and only in functions which already have unusually large stack frames. I don't consider that to be an important optimization. Given that, we can determine the maximum offset for all virtual registers before register allocation, which suffices for selection of insn constraint alternatives, and then determine the actual offset, once, after register allocation. Ian, sorry for not to be clear which resulted in this misunderstanding. What I wrote was a scheme without reload pass. I just mentioned some tasks of reload pass which should be solved in RA without the reload and whose solutions I did not discussed in details. The solution could be what you propose for example. Removing reload is a long way, imho. If we go this way, in the middle of it there would be still reload but solving less and less tasks.
Re: IRA conflict graph & alternative selection
Paolo Bonzini wrote: As for copies, I think it would be a bad decision to stick only to original (after the code selection) alternative and generate copies to satisfy this alternative. For example, if pseudo got memory instead of hard-register required by the alternative, it would be bad to generate a copy (ld/st in this case) if memory is accepted by the insn. Yes, spilling is a special case (see also PR19398). If something is spilled, "prereloads" could be rolled back for affected instructions and recomputed (possibly forcing no change on the constraints of other registers). Ick. This reminds me of the old old LRS code -- while it worked and was reasonably effective, it was bloody hard to understand and follow (one of major reasons the code never was contributed).I don't see what this kind of approach buys us when compared to having IRA deal with spill code directly. That is in brief how I see it and there are a lot of reload details missed (like virtual register eliminations or addressing displacement constraints etc). I suppose those would stay in reload? Ideally they'd all move into IRA. But I don't mind putting them off until after we have a solid handle on how to deal with the most common cases. Jeff
Re: Does gcc conform to C++ ABI?
"H.J. Lu" writes:
>>> "_ZZN1N1fEiEs": encoding of N::f::"Itanium C++ ABI" (no discriminator)
>>
>> The discriminator is optional and is up to the discretion of the
>> compiler. This doesn't matter for interoperability purposes, because
>> such names can not be referenced from other translation units anyhow.
>
> If it isn't optional, tools can't depend on it. I was wondering
> how useful it was.
Consider
namespace N {
inline char f(int i)
{
char a, b;
{
static const char *p = "Itanium C++ ABI"; // p = 1, "..." = 2
a = p[i];
}
{
static const char *p = "My ABI"; // p = 1, "..." = 2
b = p[i];
}
return a + b;
}
char
foo (int i)
{
return f (i);
}
}
There are two local variables named 'p' in the same function. You need
the discriminator to discriminate between them. That doesn't meant that
the ABI needs to prescribe the exact value which should be used for the
discriminator.
> Another issue for scope encoding. C++ ABI:
>
> ---
> Occasionally entities in local scopes must be mangled too
> (e.g. because inlining or template compilation causes multiple
> translation units to require access to that entity).
> ---
>
> seems to imply that the local symbols may have external
> linkage. Am I wrong?
You are wrong. When an inline function is expanded into multiple
translation units, and that inline function has a static variable, then
multiple translation units require access to the static variable. That
does not imply that the static variable has external linkage.
>> What do you think the symbol name should be?
>>
>
> Isn't it specified in C++ ABI?
No. The C++ ABI does not precisely specify the name mangling to use for
symbols which can not be referenced from other translation units.
Ian
Re: Incomplete Type on Pass By Value bug in g++ <4.3.0
On Fri, Feb 13, 2009 at 11:03:51AM -0800, Anthony Newnam wrote: > Thanks Joe. > > As far as I know the problem I'm seeing isn't a regression but perhaps > this script could still be useful. I don't really understand how it is > supposed to work, since it doesn't appear be working off svn updates. I haven't looked at it in years, so I can't help you there. When Janis first wrote the script gcc was still using CVS. But it should be useful as a starting point. > Should I do something like a binary svn search between revisions > 124707 and 132947? It takes such a long amount of time to compile g++, > almost a half an hour with my quad core, that it didn't seem practical > try to do build so many times. I guess there is probably a way to > build g++ without the rest of gcc, but I haven't seen an option for > it. Yes. It would suffice to only build phase 1 of g++, without any libraries, to do what you want, so that should be faster. You don't need a full bootstrap. If the endpoints you list are correct, that's 8240 revisions to search, but a binary search only needs to try ceil(log2(8240)) revisions, or 14. So if each build and test takes 30 minutes, you'll have your answer in seven hours.
Re: Incomplete Type on Pass By Value bug in g++ <4.3.0
On Fri, Feb 13, 2009 at 8:53 AM, Anthony Newnam wrote:
> I asked on gcc-help, but it seems like this list may be more
> appropriate as it deals with the gcc source.
>
> I have noticed that in my g++ <4.3.0, I am able to compile the
> following code without any errors:
> struct A;
> void foo(A);
> void bar(A* p){foo(*p);}
>
> In g++ 4.3.0 this seems to have been fixed, but I'm having a very hard
> time locating the fix for it. I was hoping that someone could point me
> in a general direction and hopefully even a changeset. I would like to
> be able to backport this to g++ 4.1.2 if possible.
>
FWIW, it failed with gcc 3.4.6 on RHEL4 and gcc 4.1.2 on RHEL5:
bad.cc: In function `void bar(A*)':
bad.cc:3: error: invalid use of undefined type `struct A'
bad.cc:1: error: forward declaration of `struct A'
bad.cc:3: error: initializing argument 1 of `void foo(A)'
--
H.J.
Re: Does gcc conform to C++ ABI?
On Fri, Feb 13, 2009 at 12:00:38PM -0800, Ian Lance Taylor wrote: > > Another issue for scope encoding. C++ ABI: > > > > --- > > Occasionally entities in local scopes must be mangled too > > (e.g. because inlining or template compilation causes multiple > > translation units to require access to that entity). > > --- > > > > seems to imply that the local symbols may have external > > linkage. Am I wrong? > > You are wrong. When an inline function is expanded into multiple > translation units, and that inline function has a static variable, then > multiple translation units require access to the static variable. That > does not imply that the static variable has external linkage. Does this mean that if you compiled some of those TUs with GCC, and some with icc, they might legitimately access different copies of the static variable? Seems odd. -- Daniel Jacobowitz CodeSourcery
Reviewing and merging lm32
Hi, A port to the Lattice Micro 32 was submitted back in December and it had some review but not merged. It is already in binutils, gdb, and newlib. gdb includes a simulator. So gcc is the last piece. The last patch posted is: http://gcc.gnu.org/ml/gcc-patches/2008-12/msg01024.html What is holding it up from being merged? Thanks. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
gcc-4.4-20090213 is now available
Snapshot gcc-4.4-20090213 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090213/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 144170 You'll find: gcc-4.4-20090213.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20090213.tar.bz2 C front end and core compiler gcc-ada-4.4-20090213.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20090213.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20090213.tar.bz2 C++ front end and runtime gcc-java-4.4-20090213.tar.bz2 Java front end and runtime gcc-objc-4.4-20090213.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20090213.tar.bz2The GCC testsuite Diffs from 4.4-20090206 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Does gcc conform to C++ ABI?
Daniel Jacobowitz writes: > On Fri, Feb 13, 2009 at 12:00:38PM -0800, Ian Lance Taylor wrote: >> > Another issue for scope encoding. C++ ABI: >> > >> > --- >> > Occasionally entities in local scopes must be mangled too >> > (e.g. because inlining or template compilation causes multiple >> > translation units to require access to that entity). >> > --- >> > >> > seems to imply that the local symbols may have external >> > linkage. Am I wrong? >> >> You are wrong. When an inline function is expanded into multiple >> translation units, and that inline function has a static variable, then >> multiple translation units require access to the static variable. That >> does not imply that the static variable has external linkage. > > Does this mean that if you compiled some of those TUs with GCC, and > some with icc, they might legitimately access different copies of the > static variable? Seems odd. Hmmm, you're right, I didn't think of that case. And, in fact, the ABI does discuss how this case should be handled, and g++ appears to do it correctly. So I was misunderstanding the issue, but I think we're still OK. HJ, do you still see a problem here? Ian
Re: Does gcc conform to C++ ABI?
On Fri, Feb 13, 2009 at 3:34 PM, Ian Lance Taylor wrote: > Daniel Jacobowitz writes: > >> On Fri, Feb 13, 2009 at 12:00:38PM -0800, Ian Lance Taylor wrote: >>> > Another issue for scope encoding. C++ ABI: >>> > >>> > --- >>> > Occasionally entities in local scopes must be mangled too >>> > (e.g. because inlining or template compilation causes multiple >>> > translation units to require access to that entity). >>> > --- >>> > >>> > seems to imply that the local symbols may have external >>> > linkage. Am I wrong? >>> >>> You are wrong. When an inline function is expanded into multiple >>> translation units, and that inline function has a static variable, then >>> multiple translation units require access to the static variable. That >>> does not imply that the static variable has external linkage. >> >> Does this mean that if you compiled some of those TUs with GCC, and >> some with icc, they might legitimately access different copies of the >> static variable? Seems odd. > > Hmmm, you're right, I didn't think of that case. > > And, in fact, the ABI does discuss how this case should be handled, and > g++ appears to do it correctly. So I was misunderstanding the issue, > but I think we're still OK. > > HJ, do you still see a problem here? > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12056 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39188 -- H.J.
Re: Does gcc conform to C++ ABI?
On Fri, Feb 13, 2009 at 4:40 PM, H.J. Lu wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12056 As I mentioned in that bug report, the C++ standard is not even clear there so it could maybe a bug with the ABI too :). -- Pinski
Re: Does gcc conform to C++ ABI?
"H.J. Lu" writes: >> HJ, do you still see a problem here? >> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12056 > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39188 Fine, but those are different problems. And I'm not sure 12056 is a real problem at all. Ian
