Re: Who should fix platforms broken by extern inline hack?
I'd like to ping these two problems :) i386-unknown-netbsdelf2.0.2 (and possibly newer versions) and i386-pc- mingw32 (latest released version) are still completely broken on mainline, as they have been for more that three months. As it turns out, I do now have access to a NetBSD system, and will look at that problem when I next get time. Thanks. When you provid a patch, I will test it. (If someone else ever wants access to a netbsd system, it's worth noting there's one on the GCC compile farm!) My understanding from 30589 is that a sufficiently recent version of mingw32 has solved the problem. The CVS version of mingw32 has the workaround, but most people aren't using the CVS mingw32 (most people aren't using the last released version anyway), so there'll be a need for a fix anyway.
Re: Hi all, just an onfo about huw to use gcc tree
Where could I find any toturial about? Could you suggest me how to start? I'm a newby in this. Thanks a lot Alle 22:30, sabato 3 marzo 2007, Richard Guenther ha scritto: > On 3/3/07, Fabio Giovagnini <[EMAIL PROTECTED]> wrote: > > Thanks for the answer. > > I go deeper in my thought so that maybe you can give me more infos about > > how I have to investagte about gcc/gdb > > > > We are developers of embedded software on board designed and build by us; > > Generally we use 16 bit cisc and 32 bits risc cpu (Renesas h8/h8s; sh 2 / > > 3 ). We write applications for automotive enviroment mainly. > > We write the code using c/c++ and we compile using gcc. > > Because of we do not have much memory (ram and flash) we develop in the > > following way: each software we write has the same communication protocol > > running on RS232 or over TCP/IP and we have a simple monitoring progarm > > able to show the contents of the memory addresses in some format (char, > > int, long, signed unsigned, strings, ecc). > > Generally we declare a global variable, we write a debug value into it > > and during the run time we read at the right moment the content of such a > > variable. > > Good. > > For avoiding to read by hand .map file produced by ld, I developed a flex > > / bison simple analizer able to extract from .map file the address of a > > symbol. So into my tool I load the .map file and I write the name of the > > variable and I can read the content of it. > > This way of working becomes very hard if I use struct and union in c and > > classes in c++; I should know the offeset of each field of the struct so > > addind it to the base address known from the .map file, for each istance > > of such a struct I coud write "mysrtuct.myfield" into my tool, and, > > calculating the rigth address, my protocol could ask the target to > > read/write the content at that address. > > > > I prefer to avoid -g option because of my memory is never enough; but a > > good compromise cound be if I could compile the debug infos into sections > > I could remove after used by gdb for giving me the informations about the > > offset of each field. Is it possible? > > Just use the dwarf info produced by the compiler with -g and strip the > binary. Of course I would debug embedded stuff using a simulator... > > Richard. -- Fabio Giovagnini Aurion s.r.l. via degli orti 11, 40050 Funo di Argelato (BO) Tel. +39.335.8350919 Fax +39.051.8659009 www.aurion-tech.com account telefono VoIP skype (www.skype.com): aurion.giovagnini
Re: Hi all, just an onfo about huw to use gcc tree
Thanks a lot for your answer. Following some question about your gdb remote stuff. Alle 02:12, domenica 4 marzo 2007, Michael Eager ha scritto: > Fabio Giovagnini wrote: > > Thanks for the answer. > > I go deeper in my thought so that maybe you can give me more infos about > > how I have to investagte about gcc/gdb > > > > We are developers of embedded software on board designed and build by us; > > Generally we use 16 bit cisc and 32 bits risc cpu (Renesas h8/h8s; sh 2 / > > 3 ). We write applications for automotive enviroment mainly. > > We write the code using c/c++ and we compile using gcc. > > Because of we do not have much memory (ram and flash) we develop in the > > following way: each software we write has the same communication protocol > > running on RS232 or over TCP/IP and we have a simple monitoring progarm > > able to show the contents of the memory addresses in some format (char, > > int, long, signed unsigned, strings, ecc). > > It sounds like you are recreating the functionality in the gdb remote. > > > Generally we declare a global variable, we write a debug value into it > > and during the run time we read at the right moment the content of such a > > variable. > > Good. > > For avoiding to read by hand .map file produced by ld, I developed a flex > > / bison simple analizer able to extract from .map file the address of a > > symbol. So into my tool I load the .map file and I write the name of the > > variable and I can read the content of it. > > This way of working becomes very hard if I use struct and union in c and > > classes in c++; I should know the offeset of each field of the struct so > > addind it to the base address known from the .map file, for each istance > > of such a struct I coud write "mysrtuct.myfield" into my tool, and, > > calculating the rigth address, my protocol could ask the target to > > read/write the content at that address. > > Yes, developing a debugger it quite time-consuming and difficult. That is > essentially what you appear to be doing. > > > I prefer to avoid -g option because of my memory is never enough; but a > > good compromise cound be if I could compile the debug infos into sections > > I could remove after used by gdb for giving me the informations about the > > offset of each field. Is it possible? > > Why is the size of your target memory an issue? Are you trying to run > the debugger on the target? No, I'm debugging on the host. The target as only a very simple read / wrire protocol. > > In most cross-development environments, the debugger (gdb) runs on > a host system and only a small portion of code (gdb remote) runs on > the target. The size of your target's memory doesn't affect the host. How big is your gdb remote stuff? > > > Where can I read more about to use gdb for embedded development with very > > poor uControllers? > > Try "info gdb" as a start. -- Fabio Giovagnini Aurion s.r.l. via degli orti 11, 40050 Funo di Argelato (BO) Tel. +39.335.8350919 Fax +39.051.8659009 www.aurion-tech.com account telefono VoIP skype (www.skype.com): aurion.giovagnini
Improvements of the haifa scheduler
Hi.
I want to share some of my thoughts and doings on improving / cleaning
up current GCC instruction scheduler (Haifa) - most of them are just
small obvious improvements.
I have semi-ready patches for about a half of them and would appreciate
any early suggestion or comments on the following draft plan:
1. Remove compute_forward_dependencies (). [Done]
Since new representation of dependencies lists was checked in, we don't
longer need to compute forward dependencies separately. It would be
natural to add forward links at the same time as we generate backward ones.
2. Use alloc_pools instead of obstacks for dep_nodes and deps_lists.
[In progress]
As pointed out by Jan Hubicka scheduler peaks +100M on a testcase for
PR28071 after my patch for new dependencies lists was checked in.
Though alloc_pools should have been my first choice while writing that
patch, I decided to mimic as close as possible the original rtx
instruction lists with their scheme of deallocation at the very end. So
the next step would be to define proper lifetime of dependency lists
and use alloc_pools to reuse nodes and lists from the previous regions.
Which brings us to ...
3. Define clear interface for manipulating dependencies. [In progress]
This one popped up when I began to debug <2> and understood that the
scheduler uses and changes dependencies lists the way it shouldn't.
Lists are being copied, edited and deleted directly without interaction
with sched-deps.c . What the scheduler really needs is the following
set of primitives:
o FOR_EACH_DEP (insn, which_list, iterator, dep) - walk through
insn's which_list (one of {backward, resolved_backward, forward,
resolved_forward}) and provide the user with the dep. Ayal Zaks
suggested this type of macro weeks ago but at that time I didn't agree
with him.
o dep_t find_dep_between (producer, consumer) - find dependency
between two instructions. Currently we walk through the list looking
for what we need. A better way would be to first check dependency
caches and then, if we can't determine that there is no dependency, walk
through the shorter list given the choice of two: producer's forward
list and consumer's backward list.
o void add_dep (dep_t) - Add a dependency.
o void remove_dep (iterator) - Remove dependency pointed out by iterator.
o void resolve_dep (iterator) - Resolve dependency pointed out by
iterator.
o int get_list_size (insn, which_list) - Get the size of the insn's
which_list.
o bool list_has_only_speculative_deps (insn, which_list) - Return
true if all insn's dependencies can be overcome with some sort of
speculation.
o void {create, delete}_dependency_lists (insn) - Create / delete
dependency lists for insn.
As you can see, the scheduler doesn't need to know the internal
representation of the deps_list / dep_node.
4. Support speculative loads into subregs. [Planned]
As noted by Jim Wilson current support for ia64 speculation doesn't
handle subregs though that would be easy to fix.
5. Make sched-deps.c mark only those dependencies as speculative which
can actually be overcame with speculation types currently in use. [Planned]
At the moment we first generate speculative dependencies and only at the
moment of adding instruction to the ready list we check if we can (or it
worth to) overcome every of its dependencies.
6. Make ds_t a structure. [Planned]
ds_t is type for representing status of a dependency. It contains
information about types of the dependency (true, output, anti) and
probabilities of speculation success (begin_data, be_in_data,
begin_control, be_in_control) - that makes three bits and for integers
coded in a single int. Historical reasons forced this inelegant
approach but now the reasons are inexistent and the problem can be
solved in a natural way.
7. Use cse_lib in sched-rgn.c . [In progress]
At the moment cse_lib works to improve alias analysis only during
sched-ebb scheduling. It is trivial that we can also enable it when
scheduling single block regions in sched-rgn. The patch for this is
a one-liner which was tested on a bootstrap but not on SPECs.
It is also possible to use cse_lib on sequential basic_blocks of the
region thus handling them as an extended basic block.
If it is possible to save cse_lib states, then we'll be able to process
trees and merging capabilities are required for DAGs. Don't know if
this can be done.
8. Don't generate a memory barrier on simplejump. [Done]
sched-deps.c handles every jump in the scheduling region as a memory
barrier - e.g. almost no memory operation can be moved through it. But
unconditional jumps don't really need such restrictions. A one-liner
patch for this was tested on the bootstrap but not on SPECs.
9. Use sched-ebb on other architectures. [Done]
After patches for ia64 speculation and follow up fixes to them sched-ebb
no longer corrupts CFG and can safely be used as not final pass on
platforms other than ia64. I successfully bootstrapped (and, pro
Re: Valid gimple for MEM_REF
Hello, > > only gimple_vals (name or invariant). However, the expressions are > >matched in final_cleanup dump (after out-of-ssa and ter), so this no > >longer is the case. I think just the regular expressions need to be > >updated. > > Then IV-OPTs has an issue too but IV-OPTs dump gives: > D.1604_5 = MEM[base: (double *) &a, index: ivtmp.34_12]; > MEM[base: (double *) &c, index: ivtmp.34_12] = D.1604_5; > > the expression matching in final_cleanup was just a symptom of the issue. OK, I will have a look at that. Zdenek
GCC project participation in the 2007 Google Summer of Code program?
Is the GCC project participating in the 2007 Google Summer of Code project? If so, is the link near the bottom of the page http://www.gnu.org/software/soc-projects/ideas.html correct? Do you have a list of project ideas? Thanks, James.
'call' is not an edge
hello all, I was wondering why "call" directives are not edges in function graphs ? I see that only jumps are edges, and calls are treated like a normal directive... thanks for the help, sunzir.
CFG question
hello ppl, when I use -fdump-rtl-all with -dv I get CFG files. where can I learn the syntax of that CFG files ? it seems some kind of LISP language... thanks ! sunzir
Re: CFG question
On 3/4/07, Sunzir Deepur <[EMAIL PROTECTED]> wrote: hello ppl, when I use -fdump-rtl-all with -dv I get CFG files. where can I learn the syntax of that CFG files ? it seems some kind of LISP language... As the fine manual says: `-dv' For each of the other indicated dump files (either with `-d' or `-fdump-rtl-PASS'), dump a representation of the control flow graph suitable for viewing with VCG to `FILE.PASS.vcg'. So my guess is that the syntax is VCG's. Gr. Steven
Re: Improvements of the haifa scheduler
Maxim Kuvyrkov wrote: Hi. I want to share some of my thoughts and doings on improving / cleaning up current GCC instruction scheduler (Haifa) - most of them are just small obvious improvements. I have semi-ready patches for about a half of them and would appreciate any early suggestion or comments on the following draft plan: 1. Remove compute_forward_dependencies (). [Done] 2. Use alloc_pools instead of obstacks for dep_nodes and deps_lists. [In progress] 3. Define clear interface for manipulating dependencies. [In progress] 4. Support speculative loads into subregs. [Planned] 5. Make sched-deps.c mark only those dependencies as speculative which can actually be overcame with speculation types currently in use. [Planned] 6. Make ds_t a structure. [Planned] 7. Use cse_lib in sched-rgn.c . [In progress] 8. Don't generate a memory barrier on simplejump. [Done] 9. Use sched-ebb on other architectures. [Done] 10. Leveled priority. [Done] 11. Implement control speculation in sched-ebb. [In progress] 12. Initialize scheduler data structures for each region separately and index them by luid. [Done] 13. Generate regions from extended basic blocks in sched-rgn.c [Planned] 14. Some sort of must alias analysis for scheduler. [Planned] Any comments, suggestions or 'please don't do that' will be greatly appreciated. It sounds as a good and interesting plan. I have no serious objection to any of these proposals. Cleaning scheduler code is definitely plan to go. I like idea for using ebb scheduler as the 2nd scheduler. As for proposed different heuristics, only benchmarking will say that but it is a good thing to try them in any case. Good aliasing is very important for the scheduler. But I'd look at this more wider. We need a good aliasing for many RTL optimizations. What's happened to ISP RAS aliasing patch propagating SSA info to RTL? Why is it stalled? As for Sanjiv Gupta's aliasing work, that was interesting but as I remember the patch made compiler too slow (like 40% slower). You should make this approach faster to make it accepted as used by default. Another important thing to do is to make the 1st scheduler register pressure sensitive. It would improve performance and solve the 1st insn scheduling problem for x86, x86_64. Now it is off by default because the scheduler moves insns containing hard regs too freely and this results in failure of the reload to find a hard register of a small class. If you need benchmarking for machines (like ppc) you have no access to, I can provide the benchmarking. I should also mention that I do all these works in my spare time which is not a lot, thus the above is my plan for about a half of the year. I really appreciate. May be if you or ISP RAS could find students (e.g. from Moscow University) to do this as Google Summer Code, it could help you. I think it is not too late. You should ask Ian Taylor or Daniel Berlin, if you want to do this.
Re: CFG question
Hi,
On 3/4/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
On 3/4/07, Sunzir Deepur <[EMAIL PROTECTED]> wrote:
> hello ppl,
>
> when I use -fdump-rtl-all with -dv I get CFG files.
> where can I learn the syntax of that CFG files ?
> it seems some kind of LISP language...
So my guess is that the syntax is VCG's.
Forgive me, I had mistake in the question - I meant the debug dump files
that we get just by using the -fdump-rtl-all. not the vcg files.
how can I understand their syntax ?
thanks..
sunzir
some example:
;; Function fun1 (fun1)
(note 2 0 3 NOTE_INSN_DELETED)
(note 3 2 6 NOTE_INSN_FUNCTION_BEG)
(note 6 3 20 [bb 1] NOTE_INSN_BASIC_BLOCK)
(insn/f 20 6 21 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [0 S4 A8])
(reg/f:SI 6 bp)) 28 {*pushsi2} (nil)
(nil))
(insn/f 21 20 22 (set (reg/f:SI 6 bp)
(reg/f:SI 7 sp)) 34 {*movsi_1} (nil)
(nil))
(insn/f 22 21 23 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int -8 [0xfff8])))
(clobber (reg:CC 17 flags))
(clobber (mem:BLK (scratch) [0 A8]))
...
...
Gr.
Steven
Re: CFG question
On 3/4/07, Sunzir Deepur <[EMAIL PROTECTED]> wrote: Forgive me, I had mistake in the question - I meant the debug dump files that we get just by using the -fdump-rtl-all. not the vcg files. how can I understand their syntax ? http://gcc.gnu.org/onlinedocs/gccint/RTL.html#RTL Gr. Steven
Re: CFG question
Hi, On 3/4/07, Steven Bosscher <[EMAIL PROTECTED]> wrote: On 3/4/07, Sunzir Deepur <[EMAIL PROTECTED]> wrote: > Forgive me, I had mistake in the question - I meant the debug dump files > that we get just by using the -fdump-rtl-all. not the vcg files. > how can I understand their syntax ? http://gcc.gnu.org/onlinedocs/gccint/RTL.html#RTL thanks, sunzir Gr. Steven
Re: 'call' is not an edge
On 3/4/07, Sunzir Deepur <[EMAIL PROTECTED]> wrote: hello all, I was wondering why "call" directives are not edges in function graphs ? Because calls don't change the control flow except when they are able to throw exceptions, or don't return. If they were to be edges, you would have something like 100 basic blocks for a simple function which is too excusive. Thanks, Andrew Pinski
Re: Improvements of the haifa scheduler
On 3/4/07, Vladimir N. Makarov <[EMAIL PROTECTED]> wrote: Another important thing to do is to make the 1st scheduler register pressure sensitive. I don't know how many times this has to be said, no this is not the correct approach to fix that issue. The correct fix is able for the register allocator to work correctly and fix up the IR. -- Pinski
Re: Massive SPEC failures on trunk
> Trunk GCC shows massive (2 compile-time and 6 run-time) failures on SPEC > CPU2000 and CPU2006 at i386 and x86_64 on -O2 optimization level. > Regression introduced somewhere between revision 122487 and 122478. I observe a massive compilation time regression for bootstrap on x86-64 here, in particular libjava now appears to take *ages* to build: revision 115944: real255m53.382s user230m40.934s sys 13m20.426s revision 116697: real257m18.998s user231m43.912s sys 13m31.991s revision 121500: real257m50.984s user230m46.276s sys 12m19.737s revision 121686: real251m52.693s user234m39.234s sys 12m8.914s revision 122521: real687m3.830s user374m37.001s sys 19m26.378s [EMAIL PROTECTED]:~/build/gcc/native> gcc/xgcc -v Using built-in specs. Target: x86_64-suse-linux Configured with: /home/eric/svn/gcc/configure x86_64-suse-linux --prefix=/home/eric/install/gcc --with-as=/home/eric/build/binutils-2_17-branch/native/gas/as-new --with-ld=/home/eric/build/binutils-2_17-branch/native/ld/ld-new --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-__cxa_atexit --enable-checking=assert,gc,misc,rtl,rtlflag,runtime,tree Thread model: posix gcc version 4.3.0 20070304 (experimental) I'm a bit puzzled by the real/user ratio, the box was supposed to be idle... -- Eric Botcazou
Re: Hi all, just an onfo about huw to use gcc tree
Fabio Giovagnini wrote: Thanks a lot for your answer. Following some question about your gdb remote stuff. How big is your gdb remote stuff? Go to the gdb website (http://www.gnu.org/software/gdb/gdb.html) and download the documentation on gdb. That should answer your questions. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: Improvements of the haifa scheduler
On 3/4/07, Andrew Pinski <[EMAIL PROTECTED]> wrote: On 3/4/07, Vladimir N. Makarov <[EMAIL PROTECTED]> wrote: > Another important thing to do is to make the 1st scheduler register > pressure sensitive. I don't know how many times this has to be said, no this is not the correct approach to fix that issue. The correct fix is able for the register allocator to work correctly and fix up the IR. Andrew, your truth isn't necessarily _the_ truth in this matter ;-) Gr. Steven
Re: Massive SPEC failures on trunk
Grigory Zagorodnev wrote: Trunk GCC shows massive (2 compile-time and 6 run-time) failures on SPEC CPU2000 and CPU2006 at i386 and x86_64 on -O2 optimization level. Regression introduced somewhere between revision 122487 and 122478. http://gcc.gnu.org/viewcvs?view=rev&revision=122487 Almost all regressions are due to r122487 cpu2006: 403.gcc 416.gamess 434.zeusmp 464.h264ref 465.tonto cpu2000: 178.galgel 186.crafty http://gcc.gnu.org/viewcvs?view=rev&revision=122484 cpu2006/447.dealII is due to revision 122484. I'll bring more information and try to get minimal reproducers at Monday. - Grigory
Re: Improvements of the haifa scheduler
Andrew Pinski wrote: On 3/4/07, Vladimir N. Makarov <[EMAIL PROTECTED]> wrote: Another important thing to do is to make the 1st scheduler register pressure sensitive. I don't know how many times this has to be said, no this is not the correct approach to fix that issue. The correct fix is able for the register allocator to work correctly and fix up the IR. I am not agree. Fixing it in RA after insn with hard register moved will result in several additional insns of course unless you implement moving insns in RA which makes it an insn scheduler. Also fixing this in the reload is much more difficult task (needs more expertise) than in the insn scheduler. Ideally integrated RA and scheduler (and code selection) would be best solution but it is not realistic becuase even after many years gcc has no decent separate scheduler and RA.
Re: Massive SPEC failures on trunk
Andrew Pinski wrote: For one, the 176.gcc in SPEC 2k has an aliasing violation in it so that failing is known. You might want to try adding -fno-strict-aliasing. In this case we would need to add -fno-strict-aliasing to CFLAGS for the whole 'int' test set, since we follow 'baseline' rules. That would result overall performance degradation. Thus we prefer alternative sources in this particular case. I have been asking someone who has the power to submit an alt to SPEC for that failure for 3 years now and now it is too late really. We have made some changes for 176.gcc in spec cpu2000 v1.3 (see http://www.spec.org/cpu2000/issues/). We can either assist in submitting issues via Intel's representative in SPEC committee later on. - Grigory
Re: Failed
On Fri, 2 Mar 2007, Andrew Pinski wrote: >> -> http://www.gnu.org/software/gcc/gcc.html >> >> Failed Validation of W3C ! >> >> This page is not Valid XHTML 1.0 Transitional ! >> >> >> W3C rules specify that XHTML tags have to be written in lowercase. >> You have just to replace every "DIV" by "div" and validation will succeed. Thanks for the report, Michel! > Plus http://gcc.gnu.org/ valids as valid XHTML 1.0 Transitional. So > something in the conversion method that www.gnu.org does to the web > pages break the validation. I investigated a bit, and it seems that unlike gcc.gnu.org, www.gnu.org lacks the latest revision (at least) of the bin/preprocess script in our wwwdocs module: revision 1.43 date: 2006/06/10 21:52:24; author: gerald; state: Exp; lines: +2 -0 Use sed to work around MetaHTML brokenness wrt. . I have contacted the GNU sysadmins and asked them to update to the latest version of the script. Gerald
Re: obsolete maintainers
On Fri, 2 Mar 2007, Mark Mitchell wrote: > OK. If any of those people decide they want to be listed again, with > new email addresses, they can let us know, and we can put them back. > > You can remove that one too: >> Alex Samuel[EMAIL PROTECTED] > Alex left CodeSourcery about five years ago. On a related note, we should start clearing accounts as well. Anyone interested? If not, I can give it a stab -- basically, everyone who has an account on gcc.gnu.org that is in the gcc group and is not listed in MAINTAINERS should be looked at. Gerald
Re: GCC project participation in the 2007 Google Summer of Code program?
> Is the GCC project participating in the 2007 Google Summer of Code > project? If so, is the link near the bottom of the page > http://www.gnu.org/software/soc-projects/ideas.html correct? Do you > have a list of project ideas? Yes, the GCC project is participating. Please see: http://gcc.gnu.org/wiki/SummerOfCode The hope is that this page will be updated for 2007 projects. Ben
Re: GCC project participation in the 2007 Google Summer of Code program?
"James Youngman" <[EMAIL PROTECTED]> writes: > Is the GCC project participating in the 2007 Google Summer of Code > project? If so, is the link near the bottom of the page > http://www.gnu.org/software/soc-projects/ideas.html correct? Do you > have a list of project ideas? Yes, we do plan to participate. That link goes to the SoC page for gcc. Right now it's still the 2006 one, but I would assume it will probably the right one once the 2007 setup gets going. Ian
Re: Who should fix platforms broken by extern inline hack?
FX Coudert <[EMAIL PROTECTED]> writes: > I'd like to ping these two problems :) > > i386-unknown-netbsdelf2.0.2 (and possibly newer versions) and i386-pc- > mingw32 (latest released version) are still completely broken on > mainline, as they have been for more that three months. This patch (not yet approved) is my contribution to fixing the problem. http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00021.html Ian
new auto-inc-dec pass
Hi,
I'mm currently looking at the dataflow branch for m68k mainly because of
the new auto-inc-dec pass, I worked a bit on the old code in flow.c, but
considering the new pass, I think it doesn't make much sense to continue
it.
I'm attaching my current patch and some test cases, but before delving
deeper into the code, I have a few questions and I'd like to hear some
opinions. Currently I only looked at the output and it misses some
opportunities (not that my patch can do everything either :) ).
One case is about multiple increments, the tree optimizer merges them and
increments the register only once, so if one only looks at the size of the
pointer value one misses them, e.g. something like this:
(set (mem (reg)) (x))
(set (mem (plus (reg) (const_int 4))) (x))
(set (reg) (plus (reg) (const_int 8))
Another case are multiple uses of the register within an instruction, the
old code didn't do this at all, the new code seems to do a bit better, but
there as a rather tricky case I looked into, e.g.
(set (mem) (plus (mem) (reg)))
could be turned into:
(set (post_inc (mem)) (plus (mem) (reg)))
or
(set (mem) (plus (pre_dec (mem)) (reg)))
This is at least what operands_match_p() accepts, but hasn't been
generated in a long time and has the potential to trigger bugs in the
back end (e.g. m68k only looks only at one of the operands).
A question would be now if there is a general interest in reactivating
this, so gcc could generate a instruction like "add.l %d0,(%a0)+" for
m68k.
The more general question is whether someone is already working on further
improvements, so I won't duplicate anything (which wouldn't be before I
looked into the remaining m68k dataflow problems anyway. :) ).
The dataflow porting document mentions other possible, but doesn't mention
any examples. Anything I might have to look out for regardings the m68k
post_inc/pre_dec addressing modes?
bye, Romanvoid f1(int *p, int i)
{
*--p = i;
}
int f1b(int *p, int i)
{
return *--p;
}
void f2(int *p, int i)
{
*--p = i++;
*--p = i;
}
int *f3(int *p, int i)
{
*p++ = i;
return p;
}
int *f4(int *p, int i)
{
*p++ = 1;
*p++ = 2;
return p;
}
int *f5(int *p, int i)
{
*p++ = i++;
*p++ = i;
return p;
}
void f6(int *p, int i)
{
while (--i) {
*p++ = 1;
*p++ = 2;
}
}
void f7(int *p, int i)
{
while (--i) {
*--p = 1;
*--p = 2;
}
}
void f8(int *p, int i)
{
*p++ = 1;
*p = 2;
}
void f9(int *p, int i)
{
*p++ += 1;
*p = 2;
}
void f10(int *p, int i)
{
*p++ = 1;
*p += 2;
}
---
gcc/flow.c | 350 ++---
1 file changed, 219 insertions(+), 131 deletions(-)
Index: gcc/gcc/flow.c
===
--- gcc.orig/gcc/flow.c
+++ gcc/gcc/flow.c
@@ -314,8 +314,9 @@ static rtx not_reg_cond (rtx);
static rtx and_reg_cond (rtx, rtx, int);
#endif
#ifdef AUTO_INC_DEC
-static void attempt_auto_inc (struct propagate_block_info *, rtx, rtx, rtx,
- rtx, rtx);
+struct inc_data;
+static void attempt_auto_inc (struct propagate_block_info *pbi, rtx insn,
+ rtx mem, struct inc_data *inc);
static void find_auto_inc (struct propagate_block_info *, rtx, rtx);
static int try_pre_increment_1 (struct propagate_block_info *, rtx);
static int try_pre_increment (rtx, rtx, HOST_WIDE_INT);
@@ -1802,7 +1803,7 @@ propagate_one_insn (struct propagate_blo
&& REG_P (SET_DEST (x))
&& (GET_CODE (SET_SRC (x)) == PLUS
|| GET_CODE (SET_SRC (x)) == MINUS)
- && XEXP (SET_SRC (x), 0) == SET_DEST (x)
+ && REG_P (XEXP (SET_SRC (x), 0))
&& GET_CODE (XEXP (SET_SRC (x), 1)) == CONST_INT
/* Ok, look for a following memory ref we can combine with.
If one is found, change the memory ref to a PRE_INC
@@ -3488,6 +3489,53 @@ elim_reg_cond (rtx x, unsigned int regno
#ifdef AUTO_INC_DEC
+struct inc_data
+{
+ rtx incr;
+ rtx reg;
+ unsigned int regno;
+ HOST_WIDE_INT offset;
+ rtx inc;
+
+ rtx *inc_loc;
+ rtx inc_val;
+ rtx inc_dest;
+ rtx *reg_dest;
+};
+
+static int
+find_inc_1 (rtx *x, void *data)
+{
+ struct inc_data *inc = data;
+
+ if (!*x)
+return 0;
+ if (GET_CODE (*x) == PLUS)
+{
+ if (inc->inc_loc)
+ return 0;
+ if (REG_P (XEXP (*x, 0)) && REGNO (XEXP (*x, 0)) == inc->regno)
+ inc->inc_val = XEXP (*x, 1);
+ else if (REG_P (XEXP (*x, 1)) && REGNO (XEXP (*x, 1)) == inc->regno)
+ inc->inc_val = XEXP (*x, 0);
+ else
+ return 0;
+ inc->inc_loc = x;
+ return -1;
+}
+ if (GET_CODE (*x) == EXPR_LIST)
+return -1;
+ if (REG_P (*x) && REGNO (*x) == inc->regno && x != inc->reg_dest)
+return 1;
+ if (GET_CODE (*x) == SET)
+{
+ rtx *y = &SET_DEST (*x);
+ if (REG_P (*y) && REGNO (*y) == inc->regno)
+ inc->reg_dest = y;
+}
+ return 0;
+}
+
/* Try to substitute the auto-inc expression INC
Re: Who should fix platforms broken by extern inline hack?
Ian Lance Taylor wrote: > FX Coudert <[EMAIL PROTECTED]> writes: > >> I'd like to ping these two problems :) >> >> i386-unknown-netbsdelf2.0.2 (and possibly newer versions) and i386-pc- >> mingw32 (latest released version) are still completely broken on >> mainline, as they have been for more that three months. > > This patch (not yet approved) is my contribution to fixing the > problem. > > http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00021.html Please let me know if you feel this has gotten stuck, and I will try to help move it forward. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GCC 4.2.0 Status Report (2007-03-04)
After reviewing all of the traffic[1] that stemmed from my previous status report, I've decided that, indeed, it makes sense to steam ahead with GCC 4.2.0 based on current GCC 4.2.0 release branch. I haven't yet made a final decision on the aliasing issue, and I'm open to suggestions about what to do there, but I do think it makes sense to proceed with the release. I still hope to build RC1 a week from today. However, I do think that it's important to eliminate some of the 139 open P2 and P1 regressions [2], especially those P1 regressions which did not appear in GCC 4.1.x. I think it's reasonable to ask that those in the MAINTAINERS file as having write privileges contribute at least one fix to the 4.2 branch, in the next week, unless there are no regressions in your area of the compiler. A la Stephen Colbert, I'll be tipping my hat or wagging my finger in my report next Monday. :-) Of course, that's not to say that non-maintainers shouldn't contribute as well! Let's get it done! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713 [1] http://gcc.gnu.org/ml/gcc/2007-02/msg00427.html [2] http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.2&target_milestone=4.0.4&target_milestone=4.1.3&target_milestone=4.2.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=
RTL insns getting deleted
Hi all, I am working with GCC 4.1.1. I had to set some target dependent flags before emitting any arithmetic instruction for floating point operation. e.g. before add operation, i need to set some flags. For that in define expand i used 1. emit_insn to set the flag (moving data to special registers). 2. emit_insn for add_float insn. 3. DONE But while checking the RTL dumps, in source.c.08.jump, the RTL insn's for the special registers are not found. It is present in all previous RTL dumps. Any specific reason why these are getting deleted and how to overcome this? Thanks in advance, Regards, Rohit.
Re: Improvements of the haifa scheduler
Vladimir N. Makarov wrote:
Maxim Kuvyrkov wrote:
Hi.
I want to share some of my thoughts and doings on improving / cleaning
up current GCC instruction scheduler (Haifa) - most of them are just
small obvious improvements.
I have semi-ready patches for about a half of them and would appreciate
any early suggestion or comments on the following draft plan:
...
Any comments, suggestions or 'please don't do that' will be greatly
appreciated.
...
Good aliasing is very important for the scheduler. But I'd look at this
more wider. We need a good aliasing for many RTL optimizations. What's
happened to ISP RAS aliasing patch propagating SSA info to RTL? Why is
it stalled?
As for Sanjiv Gupta's aliasing work, that was interesting but as I
remember the patch made compiler too slow (like 40% slower). You should
make this approach faster to make it accepted as used by default.
I understand that good aliasing is important for several RTL passes and
I hope that the general aliasing support will improve in time. I must
admit that I didn't investigate the Gupta's patch yet, but I believe
that it is so slow because it needs to rescan the function many times in
order to get correct aliasing information. On the other hand alias
analysis for scheduler's data speculation has a luxury of being not
correct at times. So it looks like a low hanging fruit to me to try
fast but not safe variant of Gupta's work and see if the magic will happen.
Another important thing to do is to make the 1st scheduler register
pressure sensitive. It would improve performance and solve the 1st insn
scheduling problem for x86, x86_64. Now it is off by default because
the scheduler moves insns containing hard regs too freely and this
results in failure of the reload to find a hard register of a small class.
If you need benchmarking for machines (like ppc) you have no access to,
I can provide the benchmarking.
I should also mention that I do all these works in my spare time which
is not a lot, thus the above is my plan for about a half of the year.
I really appreciate. May be if you or ISP RAS could find students (e.g.
from Moscow University) to do this as Google Summer Code, it could help
you. I think it is not too late. You should ask Ian Taylor or Daniel
Berlin, if you want to do this.
The projects I've described are too small to qualify as a 3 months
works. But your suggestion to solve the 'scheduler -> ra' problem I
would estimate just like the right one.
The other GSC project might be to investigate and fix the places in
compiler where exported from tree-ssa aliasing information is being
invalidated.
So basically here are three Google Summer of Code projects:
o Scheduler -> RA
o Fix passes that invalidate tree-ssa alias export.
o { Fast but unsafe Gupta's aliasing patch, Unsafe tree-ssa alias
export } in scheduler's data speculation.
Ian, Daniel, what do you think?
Thanks,
Maxim
