Re: GCC 5 & modularity
On Wed, Mar 21, 2012 at 3:47 AM, Basile Starynkevitch wrote: > On Tue, 20 Mar 2012 18:39:40 +1000 > Peter Dolding wrote: >> >> The top level modules already exist and are named. > > > Not really. I see nowhere on the GCC site a picture as clear as > the "plateform overview" figure on http://developer.gnome.org/ > And I am not able to list and name corresponding modules. > If you do, please send a link or make an exhaustive list. > > The internal executables like cc1 are too high. > > For example, my feeling is that GCC (actually cc1) is made of three layers > > front-ends | middle-end | back-ends Back-ends are shared between all languages gcc supports but can be target particular.. So they are already a kind of module in there own right. Middle-end is language neutral. Yes these are basically already a module just not broken down enough. front-ends part in cc1 is the only part that is fully unique to cc1. The middle-end and back-ends you will find used with other languages as is. This here is a very good read. http://www.cse.iitb.ac.in/grc/intdocs/gcc-conceptual-structure.html For the official harder to read form http://gcc.gnu.org/onlinedocs/gccint.pdf basically this really needs some graphics added. And a little sorting. But the same information is in there as the gcc conceptual structure write up. Even better gccint.pdf goes into what c files should be in each module. This is why you hitting the wall that gcc is already kinda module design. Everything is sorted to go into modules is just starting cutting. Note I said exist and named. I did not say they were into a simple to read graphic on the gcc site. Peter Dolding
Re: GCC 5 & modularity
On Wed, Mar 21, 2012 at 10:36 AM, Peter Dolding wrote: > On Wed, Mar 21, 2012 at 3:47 AM, Basile Starynkevitch > wrote: >> On Tue, 20 Mar 2012 18:39:40 +1000 >> Peter Dolding wrote: >>> >>> The top level modules already exist and are named. >> >> >> Not really. I see nowhere on the GCC site a picture as clear as >> the "plateform overview" figure on http://developer.gnome.org/ >> And I am not able to list and name corresponding modules. >> If you do, please send a link or make an exhaustive list. >> >> The internal executables like cc1 are too high. >> >> For example, my feeling is that GCC (actually cc1) is made of three layers >> >> front-ends | middle-end | back-ends > > Back-ends are shared between all languages gcc supports but can be > target particular.. So they are already a kind of module in there own > right. > > Middle-end is language neutral. Yes these are basically already a > module just not broken down enough. > > front-ends part in cc1 is the only part that is fully unique to cc1. > The middle-end and back-ends you will find used with other languages > as is. > > This here is a very good read. > http://www.cse.iitb.ac.in/grc/intdocs/gcc-conceptual-structure.html > > For the official harder to read form > http://gcc.gnu.org/onlinedocs/gccint.pdf basically this really needs > some graphics added. And a little sorting. But the same information > is in there as the gcc conceptual structure write up. > > Even better gccint.pdf goes into what c files should be in each module. > > This is why you hitting the wall that gcc is already kinda module > design. Everything is sorted to go into modules is just starting > cutting. > > Note I said exist and named. I did not say they were into a simple to > read graphic on the gcc site. Indeed. There is also different module hierarchies that overlap. For example ILs used in the different parts of the compiler. I think Basile is mostly confused about what files belong to what module, a question with not a single answer per file. It's been suggested before, but moving files into subdirectories might help here, at least for those which have a clearly defined module. The C frontend is one obvious example, generator programs for machine descriptions another, RTL optimization passes are harder, GIMPLE/SSA optimization passes are somewhat hard, ... there is not always a good directory to put things in. For example I absolutely hate the suggested gimple/ Richard. > Peter Dolding
Re: GCC 5 & modularity
On Wed, Mar 21, 2012 at 7:57 PM, Richard Guenther wrote: > Indeed. There is also different module hierarchies that overlap. For > example ILs used in the different parts of the compiler. > > I think Basile is mostly confused about what files belong to what module, > a question with not a single answer per file. It's been suggested before, > but moving files into subdirectories might help here, at least for those > which have a clearly defined module. The C frontend is one obvious > example, generator programs for machine descriptions another, > RTL optimization passes are harder, GIMPLE/SSA optimization > passes are somewhat hard, ... there is not always a good directory > to put things in. For example I absolutely hate the suggested gimple/ > > Richard. I see all the IL as storage/modules. That transfer data between modules. Breaking into modules does not mean a module cannot be dependant on a different one. So we could have a stack of modules dependant on particular IL module. So Generic IL, Gimple IL, RTL IL would have modules in there own right containing the code shared between optimisers and the like. SSA processing of Gimple if the functions it using is used by nothing else its SSA code. Taking what gcc is and making into modules is just takes obeying a few simple rules. 1 imports into your section have to come from other modules not lossy shared files.(current confusion is lossy shared files) 2 there is no such thing as grey. If a file is shared between two modules it must be in a third module. If file exists in both modules you have split incorrectly. If there is a grey area you have broken into modules wrong. Module based code has no grey. No grey equals less errors of person editing a file they think is exclusive to some part that turns out to be shared with another part so causing nasty failure. Like Gimplification has to be dependant on two modules for C. Generic IL and Gimple IL. Most diagrams currently try to put it either in front end or middle end. When in fact its the bridge module between front end and back end and its accessing data from both sides. Once you start breaking modules correctly. SSA is simple its just SSA. With correct modules knowing what you are going to ruin by touching a file become simpler. So yes there should be a gimple/ directory but it should only contain the shared functions and the internal code those shared functions use to drive the gimple IL. Repeat the same for RTL and Simple. If you have broken everything right you should basically be able to pull off building all the modules as .so/.dll files bar the core application and have application work. There should be a single answer per file Richard Guenther. It is critical there is. So you know what you are working on. Of course there are going to be a few files as cutting starts where if we do a detailed design straight up when cutting starts its going to be o bugger we need to create another module here so the code base is clean. We have the basic overview. The question is were to start cutting. Cutting front end stuff that is obvious would be a very good starting point. I don't expect gcc hierarchies to be a nice clean shape. But it should be able to be made cleaner. So if I want to adjust like a front end I know I am adjusting just the front end not something else. Same with SSA that I am fixing a bug in SSA I know that the files I am currently touching SSA only uses. Finally I know if I am playing in any of the IL directories I am playing with fire. Of course with SSA it might have subdirectories under it for code sections that can be edited without effecting everything. This is where breaking into modules is good you can see how much risk you are taking. Personally in my eyes it time to start cutting into directories and shaping the code up to neat. Remove the left over layout from prior to IL being used a lot inside gcc. Basically we have the overview roughly how the code should look when modules. The final overview of the code as modules can only be done after its chopped up into modules. There is no requirement to chop it all at once. Trying to chop it all at once may not give enough time to work out how to correctly cut any overlapping parts that turn up. So realistic goal should be a particular area chopped correctly. Each chop equals altering makefiles and moving files. Slow can careful is required when doing this is required. Each chop could bring failure. A chop per point release most likely would be too careful. Basically Gcc 5=modular should a little of an extrema goal when we have not made a decent percentage modular yet. We have to get to proper half or more modules before we really should set a goal like this. Once there is a clearer idea of the issues that will happen. Peter Dolding
Re: gcc-4.6.3 ICE
>> Thank you for the quick reply. >> OKay, follow up from a few days ago. I ran the testsuite again however with a stack size of 32Mb and now there are no ICE issues. See : http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02401.html What I find interesting is why we see an internal compiler error as opposed to something more reasonable when the user stack size is too small. Really, this is not a compiler fault at all but a user environment issue and thus the ICE is a false alarm. dc -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: gcc-4.6.3 ICE
On Wed, 21 Mar 2012, Dennis Clarke wrote: > What I find interesting is why we see an internal compiler error > as opposed to something more reasonable when the user stack size is > too small. Really, this is not a compiler fault at all but a user > environment issue and thus the ICE is a false alarm. I suppose we could use sigaltstack where available and a signal handler to detect stack overflow on suitable hosts to give a better message. It ought to be possible to use -fsplit-stack to avoid stack overflow - it would be interesting to know if that works (if GCC is built with -fsplit-stack, and linked with gold, on a host for which this is properly supported) and how it affects GCC's performance. -- Joseph S. Myers jos...@codesourcery.com
Re: Cloning functions
> Hello, > In my transformation of an input program, I need to clone functions > and the callee functions in each clone. To clone a function, or > create a duplicate, I use "cgraph_function_versioning()" This works > perfectly well for the parent function. I then go through the > statements in the parent and look for any function calls (callees). > If I find a function call, I clone that function and update the call > site using "gimple_call_set_fn()" Now, when I dump the gimple via > "debug_function()" I see everything as I expect (parent-clone calls > all the callee-clones). The parent and all of its callees are the > clones I want. However, when GCC finishes compiling things, the > callee clones are no where to be found. And the original (non-clone) > calleess are being used. The parent-clone is there but all of the > callsites are using the original callees and not the clones. I know > there must be some update routine, (rebuild_cgraph_edges() did not > help) to glue the callee clones in place so that they do not revert > back to the original callee. Hi, it seems that you are not redirecting the calls to the newly formed clone, so the clones gets optimized out. You can look at cgraph_redirect_edge_callee uses in ipa-cp to see how this is done. Note that there are two mechanizms for clonning functions, the real clones you use and virtual clones. It depends on what you are trying to do on what is better for you. Can you elaborate more on your pass? Honza > > I hope I haven't been too confusing, I do appreciate any help if possible. > > -Matt
gnatmake: "xgnatugn.ali" incompatible ALI file, please recompile
I have hit a rather annoying issue during "make install" thus : . . . gmake ada/doctools/xgnatugn gmake[3]: Entering directory `/opt/bw/src/gcc-4.6.3-SunOS5.8-i386/gcc' mkdir -p ada/doctools cp -p ../../gcc-4.6.3/gcc/ada/xgnatugn.adb ada/doctools cd ada/doctools && gnatmake -q xgnatugn gnatmake: "xgnatugn.ali" incompatible ALI file, please recompile gnatmake: "xgnatugn.adb" compilation error gmake[3]: *** [ada/doctools/xgnatugn] Error 4 gmake[3]: Leaving directory `/opt/bw/src/gcc-4.6.3-SunOS5.8-i386/gcc' gmake[2]: *** [doc/projects.texi] Error 2 gmake[2]: Leaving directory `/opt/bw/src/gcc-4.6.3-SunOS5.8-i386/gcc' gmake[1]: *** [install-gcc] Error 2 gmake[1]: Leaving directory `/opt/bw/src/gcc-4.6.3-SunOS5.8-i386' gmake: *** [install] Error 2 I'm not sure what the issue really is. This was a nice clean three stage bootstrap build with good test results however install fails as seen above. Any enlightened thoughts would be welcome. dc -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: Cloning functions
> Hi Martin, thanks very much for the information! > > On Tue, Mar 20, 2012 at 9:29 PM, Martin Jambor wrote: > > Hi, > > > > On Tue, Mar 20, 2012 at 02:07:17PM +1100, Matt Davis wrote: > >> Hello, > >> In my transformation of an input program, I need to clone functions > >> and the callee functions in each clone. To clone a function, or > >> create a duplicate, I use "cgraph_function_versioning()" This works > >> perfectly well for the parent function. I then go through the > >> statements in the parent and look for any function calls (callees). > >> If I find a function call, I clone that function and update the call > >> site using "gimple_call_set_fn()" Now, when I dump the gimple via > >> "debug_function()" I see everything as I expect (parent-clone calls > >> all the callee-clones). The parent and all of its callees are the > >> clones I want. However, when GCC finishes compiling things, the > >> callee clones are no where to be found. > > > > And do you change the calls in the callers of the "parent function?" > > This is exactly what you would see if you don't. See convert_callers > > and convert_callers_for_node in tree-sra.c (ipa_modify_call_arguments > > is probably equivalent to gimple_call_set_fndecl for your purposes). > > Actually, I do change the calls in the parent function. What I had to > do was set the 'cfun' to the parent function, and then run > 'rebuild_cgraph_edges()' and 'cleanup_tree_cfg()' rebuidl_cgraph_edges just looks at the function body and makes edges accordingly. It is not doing eny redirection. The way redirection is usually done is that you call cgraph_redirect_edge_callee and redirect edge to your clone. Updating of statements is done alter, at the end of IPA stage via cgraph_redirect_edge_call_stmt_to_callee > > Yes, my pass is really late, after all IPA passes have complete. Once > again, thank you for your insight! This will be probably the problem, since then the redirection is not done. You can try to simply call cgraph_redirect_edge_call_stmt_to_callee after each redirection. But why you need to do IPA pass so late? Honza > > -Matt
Re: gcc-4.6.3 ICE
"Joseph S. Myers" writes: > On Wed, 21 Mar 2012, Dennis Clarke wrote: > >> What I find interesting is why we see an internal compiler error >> as opposed to something more reasonable when the user stack size is >> too small. Really, this is not a compiler fault at all but a user >> environment issue and thus the ICE is a false alarm. Btw., the problem is long known: PR c/35608. > I suppose we could use sigaltstack where available and a signal handler to > detect stack overflow on suitable hosts to give a better message. Agreed. > It ought to be possible to use -fsplit-stack to avoid stack overflow - it > would be interesting to know if that works (if GCC is built with > -fsplit-stack, and linked with gold, on a host for which this is properly > supported) and how it affects GCC's performance. That's a Linux-only option, unfortunately. I asked the Solaris engineers about implementing split-stack support, but they rejected it for the complexity. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: GCC 5 & modularity
On Wed, Mar 21, 2012 at 10:57:08AM +0100, Richard Guenther wrote:
>
> Indeed. There is also different module hierarchies that overlap. For
> example ILs used in the different parts of the compiler.
>
> I think Basile is mostly confused about what files belong to what module,
> a question with not a single answer per file. It's been suggested before,
Sorry people, we don't have any established list of named modules. I see
nowhere a list of one or two dozens of modules with for each of them:
* a name
* short description in one or two sentences
* the entire set of files or directories implementing that module
* the API of that module (perhaps as a public header file, with the strong
requirement that internal functions should be declared in a private header
file)
Again, I take as a good example GTK/Gnome. It has a documented set of named
modules, there is a figure explaining their organization and a table listing
all of them, and each module has a documentation and a set of header files
defining its interface. It has also a naming convention: in C, all the
public identifiers of a module starts by the same prefix (e.g.
GtkSourceView); in C++ the interface is inside a single C++ namespace. At
last, it has a crystal clear file heararchy which, for a given file, makes
finding to which module it belongs very easy (often the parent or
grand-parent directory gives the name of the module).
So far, I was not even able to find a list of modules names of GCC. and for
each module, the set of source files implementing it (and the set of public
header files defining its interface at the very least).
And no reply even mentionned any module names. We badly need that some
people with a *global* understanding of GCC (these are few, I am not of
them) propose a list of module *names* to be discussed.
For exmpla, I have absolutely no idea if the register allocator is one
module (or perhaps two, and probably none) or if it is just part of the
backend RTL passes
I'm quite surprised no one mentionned how it is difficult to explain GCC to
a newscomer (e.g. some student wanting to work on GCC within a GSOC). This
is partly the case because we cannot make a short list of modules. And to
ease the understanding effort, that list should be reasonably short. We
should have a list of 7-30 modules at most (I agree that some of these
modules could be further defined as made of several sub-modules). And each
of these modules should have a unique name. Each of these modules should
also have a small "title" sentende describint what it does (in a dozen
English words). At last, such a description should be part of the internal
documentation. http://gcc.gnu.org/onlinedocs/gccint/ should have a chapter
(probably after "3. http://gcc.gnu.org/onlinedocs/gccint/Interface.html";)
perhaps titled "organization of GCC in toplevel-modules" explaining all
this.
We are far from that. We first need to discuss a set of proposed module
names and titles. (Unfortunately, I am not able to propose it, because I
don't have a global knowledge of GCC; I expecte the few "global reviewers"
to have enough such knowledge.)
Once we have a proposal for modules names and titles we can discuss them,
and dive more deaper into a modular organization of GCC. (I really think we
cannot discuss of things which stay ill-defined and un-named).
Regards.
PS. Again, I don't have a large enough knowledge of GCC to even propose a
list of modules.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: GCC 5 & modularity
Em 21/03/2012 08:58, Peter Dolding escreveu: If there is a grey area you have broken into modules wrong. Module based code has no grey. No grey equals less errors of person editing a file they think is exclusive to some part that turns out to be shared with another part so causing nasty failure. This seems a Game of Words [tm]. Of course a modularized system can have a grey area. You just pack all of your gray area files and call them "grey module" to satisfy the bureaucracy. There is no perfect taxinomy in this world. Searching for one is interesting; demanding one is useless. -- P.
Region array SSA
Hello, I am a PhD student studying compilers. I am wondering, is there any representation of array regions in the gcc/g++ IR? (Like in this paper: http://dl.acm.org/citation.cfm?id=1152165). I am having quite a hard time understanding how to build this IR from the paper. Does anyone on this list have experience with this IR or any array SSA form? I want to use this in my research, so I would be interested in paying a small consulting fee if someone was able to give me real advice/algorithms/help on constructing an array SSA form like the one in the paper. Thanks for any help, Phil Pratt-Szeliga Syracuse University
Re: GCC 5 & modularity
On Wed, Mar 21, 2012 at 4:02 PM, Pedro Lamarão wrote: > Em 21/03/2012 08:58, Peter Dolding escreveu: > > >> If there is a grey area you have broken into modules wrong. Module >> based code has no grey. No grey equals less errors of person editing >> a file they think is exclusive to some part that turns out to be >> shared with another part so causing nasty failure. > > > This seems a Game of Words [tm]. > > Of course a modularized system can have a grey area. You just pack all of > your gray area files and call them "grey module" to satisfy the bureaucracy. > > There is no perfect taxinomy in this world. Searching for one is > interesting; demanding one is useless. Very well said. Discussing about modules also makes no sense. Figure out the present state. Richard. > -- > P. >
Re: GCC 5 & modularity
On Wed, Mar 21, 2012 at 10:03 AM, Basile Starynkevitch wrote: > Sorry people, we don't have any established list of named modules. I see > nowhere a list of one or two dozens of modules with for each of them: > > * a name > > * short description in one or two sentences > > * the entire set of files or directories implementing that module > > * the API of that module (perhaps as a public header file, with the strong > requirement that internal functions should be declared in a private header > file) You appear to have a better understanding of what a module in GCC should be. Would you mind leading the pack by sending patches for evaluation and review? I am afraid an abstract lecture would not be enough. -- Gaby
Re: GCC 5 & modularity
On Wed, Mar 21, 2012 at 10:24:54AM -0500, Gabriel Dos Reis wrote:
> On Wed, Mar 21, 2012 at 10:03 AM, Basile Starynkevitch
> wrote:
>
> > Sorry people, we don't have any established list of named modules. I see
> > nowhere a list of one or two dozens of modules with for each of them:
> >
> > * a name
> >
> > * short description in one or two sentences
> >
> > * the entire set of files or directories implementing that module
> >
> > * the API of that module (perhaps as a public header file, with the strong
> > requirement that internal functions should be declared in a private
> > header
> > file)
>
>
> You appear to have a better understanding of what a module in GCC should be.
> Would you mind leading the pack by sending patches for evaluation and review?
> I am afraid an abstract lecture would not be enough.
>
I am not sure what you expect from me. As I said many times, I have not a
global understanding of GCC (the "global reviewers" have a much better
global understanding than I do). So I cannot propose or initiate a list of
modules.
Or do you want me to just propose a documentation patch with a canvas or
frame for other poeple to fill?
I would be happy to help, but please understand that my understanding of GCC
is restricted to gengtype, ggc, and some parts of the middle-end. I know
nothing about the vast rest of the GCC compiler.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: gcc-4.6.3 ICE
Rainer Orth writes: > That's a Linux-only option, unfortunately. I asked the Solaris > engineers about implementing split-stack support, but they rejected it > for the complexity. Wimps. The split-stack support is simpler than than TLS support. Not that I really think gcc should use split-stack, split-stack is more for threaded programs. I think for gcc sigaltstack is a fine solution. Ian
Re: fold_builtin changes tree
On 20/03/12 10:30, Jakub Jelinek wrote:
>
Like any other builtin expander? There are many dozens of examples in
builtins.c. It is called with the tree argument, so you verify it, complain
if the argument is not the one you are expecting, and just expand it as the
symbol instead of expanding the call. Basically you could do what you
currently do in the folder, and feed what you'd return from that to
expand_normal or expand_expr.
Jakub
Thanks Jakub. I guess that might work but I have to reimplement my
function since part of my folder would look for the initial function
definition.
So, for example if I had:
int lt(int x) { return x < 0;}
int sizeof_lt(void) { return __function_size(lt); }
Since lt, argument to __function_size, is not void (*) (void), the that
got the folder was:
void (*lt.TEMP)(void) = lt;
return __function_size(lt.TEMP);
So in the folder I was looking through the sequence of statements to
find the real function lt from the argument to __function_size: lt.TEMP.
This in the expander doesn't work anymore since we now have basic blocks
and are handling gimple instead of trees.
If you have any further suggestions, let me know.
Thanks.
--
PMatos
Re: Freescale 68HC11/68HC12 port (gcc newbie help request)
On Wed, 2011-01-26 at 14:55 +, James Murray wrote:
> On Wed, 2011-01-26 at 15:40 +0100, Richard Guenther wrote:
>
> > Stephane Carrez is listed as maintainer of the port, so he should
> > know how to contribute fixes to the port upstream.
> >
> Yes, but as I said... he is no longer active on this port. His last
> published contributions are 4+ years ago.
I've spent a some time looking at this and can honestly say I'm very
likely out of my depth.
As a first step in bringing the port forwards, I worked on 3.4.4 as that
was fairly contemporary with 3.3.6. I manually applied the changes that
Stephane Carrez had made. The compiler builds and can generate code.
However, the generated code isn't as good as the output from 3.3.6. I
swapped back to unpatched 3.4.4 and compared with unpatched 3.3.6.
Take the following example:
#define PORTA(*((volatile unsigned char*)(0x)))
#define PORTB(*((volatile unsigned char*)(0x0001)))
#define PORTT(*((volatile unsigned char*)(0x0240)))
#define SYNC_SYNCED 0x1
#define SYNC_SEMI 0x8
#define SYNC_SEMI2 0x10
extern unsigned char synch;
int main()
{
if ((PORTT & 0x01) == 0) {
PORTA |= 0x80;
}
if (PORTT & 0x02) {
PORTA |= 0x40;
}
if ( (!(synch & SYNC_SYNCED)) && (!(synch & SYNC_SEMI)) && (!(synch
& SYNC_SEMI2))) {
PORTB = 0x23;
}
return (0);
}
m68hc11-elf-gcc -g -Wall -Werror -O -fomit-frame-pointer -m68hcs12
-mshort -msoft-reg-count=5 -mauto-incdec -fsigned-char -S test4.c
With 3.3.6 (unpatched), the resultant code (trimmed) is:
main:
ldab576
clra
andb#1
bne .L2
tfr d,x
bset0,x, #-128
.L2:
ldab576
clra
andb#2
beq .L3
bset0, #64
.L3:
ldabsynch
clra
andb#25
bne .L4
movb#35,1
.L4:
clra
clrb
rts
The 8bit bit tests are a little sub-optimal, but workable.
Now, with 3.4.4
main:
movw_.d1,2,-sp
ldab576
clra
eorb#1
anda#0
andb#1
tbeqd,.L2
.LM3:
bset0, #-128
.L2:
ldab576
anda#0
andb#2
tbeqd,.L3
bset0, #64
.L3:
xgdx
clra
ldabsynch
tfr d,x
anda#0
andb#1
tbned,.L4
tfr x,d
anda#0
andb#8
tbned,.L4
tfr x,d
anda#0
andb#16
tbned,.L4
movb#35,1
.L4:
ldd #0
movw2,sp+,_.d1
rts
This resultant code is significantly larger and slower. I was able to
backtrack through SVN to the majority of this change:
2003-07-02 Jeff Law
* expr.c (do_store_flag): Remove special case folding for
single bit tests. Instead call back into the commonized folder
routine.
* fold-const.c (fold_single_bit_test): New function, mostly
extracted from do_store_flag, with an additional case extracted
from fold.
(fold): Call fold_single_bit_test appropriately.
* tree.h (fold_single_bit_test): Prototype.
The changes there adversely impacted the hc11 output. The code generated
immediately after this change is even worse than the 3.4.4 output above
- instead of "andb #8" the code does three right-shifts before "andb #1"
i.e.
---
.L2:
ldab576
lsrd
clra
andb#1
beq .L3
.loc 1 17 0
bset0, #64
.L3:
xgdx
clra
ldabsynch
xgdx
stx _.d1
tfr x,d
clra
andb#1
bne .L4
ldd _.d1
lsrd
lsrd
lsrd
clra
andb#1
bne .L4
ldd _.d1
lsrd
lsrd
lsrd
lsrd
clra
andb#1
bne .L4
movb#35,1
.L4:
---
I'm sure that the changes must have had a positive effect on other
targets, but the core of that code (.L3-.L4) is five times larger than
the 3.3.6 output.
What would be the best approach to address issues like this?
Create new m68hc11.md rules to pick up the newly generated RTL and turn
it back into optimal code or???
i.e. if Stephane Carrez had continued maintaining the m68hc11 target,
how would he have been keeping up with core changes that had a negative
impact on m68hc11 ?
My rationale here is that if I'm unable to make changes to preserve
output code quality for a small change like this, then there is no
chance of me working through the other eight years of changes...(!)
The alternative is that I work on adding a few enhancements to 3.3.6 as
that's what is being used in production by a number of differen
Re: Freescale 68HC11/68HC12 port (gcc newbie help request)
James Murray writes: > However, the generated code isn't as good as the output from 3.3.6. I > swapped back to unpatched 3.4.4 and compared with unpatched 3.3.6. I can understand why you are doing this. However, you should be aware that the compiler internals changed significantly in version 4.0. Time spent working on detailed optimizations of gcc 3.4 is almost certainly time wasted. Walking forward version by version makes some sense, I guess, but you shouldn't even look at the optimizations in the generated code until you get to at least 4.3. Ian
Re: GCC 5 & modularity
On Thu, Mar 22, 2012 at 1:03 AM, Basile Starynkevitch wrote: > On Wed, Mar 21, 2012 at 10:57:08AM +0100, Richard Guenther wrote: >> >> Indeed. There is also different module hierarchies that overlap. For >> example ILs used in the different parts of the compiler. >> >> I think Basile is mostly confused about what files belong to what module, >> a question with not a single answer per file. It's been suggested before, > > > Sorry people, we don't have any established list of named modules. I see > nowhere a list of one or two dozens of modules with for each of them: > > * a name > > * short description in one or two sentences > > * the entire set of files or directories implementing that module > > * the API of that module (perhaps as a public header file, with the strong > requirement that internal functions should be declared in a private header > file) > We have more than two dozen. http://gcc.gnu.org/onlinedocs/gccint.pdf again every header and dot point in section 9 would be a module. Then there is the supporting bits to those modules.like the IL's and the runtime. Section 9 is basically the abridged overview. So there will be a lot more modules than what is listed. Yes what you describing is a clean up of gccint documentation to be more readable and practical. Also you are describing the chopping process. Yes we do have a list of what is what in documentation. Is is currently really nice to use no its not. Its it fully detailed as it should be no its not. Is the problem huge yes it is. Breaking into modules gcc will have a more complex layout than gnome does. Due to the way thing interact. Most likely will not fit well into a 2d graphic. Most likely will fit well into a 3d graphic. So yes gccint is the starting block. Some are nicely described with what functions own to the module some are not. Imports and exports are not well declared. It is going to have to be a piece by peice prcoess Peter Dolding
Re: GCC 5 & modularity
On 21 March 2012 15:35, Basile Starynkevitch wrote: >> > > I am not sure what you expect from me. As I said many times, I have not a > global understanding of GCC (the "global reviewers" have a much better > global understanding than I do). So I cannot propose or initiate a list of > modules. > > Or do you want me to just propose a documentation patch with a canvas or > frame for other poeple to fill? Why not start a wiki page? There's no need for patch approval and anyone can make edits to improve it gradually over time. If the initial version is wrong someone can change it, but at least it will have been started.
Re: GCC 5 & modularity
Very well said. Discussing about modules also makes no sense. Figure out the present state. these kind of meta discussions are very rarely of value, this one is no exception IMO Richard. -- P.
Re: GCC 5 & modularity
On 3/21/2012 11:35 AM, Basile Starynkevitch wrote: I would be happy to help, but please understand that my understanding of GCC is restricted to gengtype, ggc, and some parts of the middle-end. I know nothing about the vast rest of the GCC compiler. Perhaps suggestions about improvements in the modularity of gcc would be better left up to those who DO have a global understanding of the existing structure of gcc.
RE: dep question in sched-deps.c
anyone can help on this question please? thanks
> From: blue_3...@hotmail.com
> To: gcc@gcc.gnu.org; maxim.kuvyr...@gmail.com
> Subject: dep question in sched-deps.c
> Date: Wed, 21 Mar 2012 01:17:07 +
>
>
> Hello,
>
> I am confused by following piece of code in sched-deps.c. My understanding is
> the last_pending_memory_flush only holds jumps, calls and memory write. So I
> think the two invocations of add_dependence should build true dependence, not
> anti.
>
>
>
> for (u = deps->last_pending_memory_flush; u; u = XEXP (u, 1))
> {
> if (! NON_FLUSH_JUMP_P (u))
> add_dependence (insn, XEXP (u, 0), REG_DEP_ANTI); <---
> else if (deps_may_trap_p (x))
> {
> if ((sched_deps_info->generate_spec_deps)
> && sel_sched_p () && (spec_info->mask & BEGIN_CONTROL))
> {
> ds_t ds = set_dep_weak (DEP_ANTI, BEGIN_CONTROL,
> MAX_DEP_WEAK);
> note_dep (XEXP (u, 0), ds);
> }
> else
> add_dependence (insn, XEXP (u, 0), REG_DEP_ANTI); <---
> }
> }
>
>
> also, can you explain following comments in sched-deps.c. I don't quite
> understand what is means and what NON_FLUSH_JUMP_KIND is for.
>
> /* In deps->last_pending_memory_flush marks JUMP_INSNs that weren't
> added to the list because of flush_pending_lists, stands just
> for itself and not for any other pending memory reads/writes. */
>
>
>
> I also need more dicussion about DEPS_LIST and INSN_LIST. Maxim once kindly
> explained to me,
> "DEPS_LIST is a super-set of INSN_LIST. I kept INSN_LIST-style dependencies
> to avoid overhead on targets that don't need additional features of
> DEPS_LIST. Now that I look back at it, I should have removed INSN_LIST-style
> dependencies; I still hope to find time and clean that up (remove support for
> INSN_LIST-style dependencies).". But it is still over my head. my question is
> what is INSN_list-style dependencies? what is the extra feature of DEPS_LIST
> as a super-set of INSN_list?
>
> thanks
