ipa for fortran question
Recently I have tried to run Spec2000 fortran benchmarks with -fwhole-program and -combine flags. It looks like there was no effect of really combining files into one program, i.e. they are processed separately at ipa level. I wonder what's the reason for this. Pointing to relevant docs will work for me. Olga
Re: ipa for fortran question
> > Recently I have tried to run Spec2000 fortran benchmarks > with -fwhole-program and -combine flags. It looks like > there was no effect of really combining files into > one program, i.e. they are processed separately at ipa level. > > I wonder what's the reason for this. > Pointing to relevant docs will work for me. --combine has no effect to fortran, but in general concatenating all the sources to one big source with cat works just fine. Fortran however has problems with the multiple declaration rule making IPA quite ineffective :( (each time something is re-declared in source new declaration is produced and IPA thinks those are different objects) Honza > > Olga
Re: RFC: Simplify rules for ctz/clz patterns and RTL
* I would like to do the same for __builtin_ctz, but there is a catch. The synthetic ctz sequence in terms of popcount (as presently implemented by ia64.md, and potentially usable for at least i386 and rs6000 as well if moved to optabs.c) produces the canonical behavior at zero, but the synthetic sequence in terms of clz (as presently implemented by optabs.c) produces the value -1 at zero. I have not been able to think of any refinement to that sequence that would reliably produce GET_MODE_BITSIZE(mode) at zero in an efficient manner. Furthermore, -1 is the value most convenient for implementing ffs in terms of ctz. Opinions and/or clever bit manipulation hacks would be much appreciated. I suppose you're using (assuming 32-bit) ctz(x) := 31 - clz(x & -x) now, which gives -1 for 0; and the version you're looking for is ctz(x) := 32 - clz(~x & (x-1)) which gives 32 for 0. (Straight from the venerable PowerPC Compiler Writer's Guide, btw). What does the popcount version look like? Never seen that before, but I think it will be really expensive on PowerPC. Segher
RE: [CFG] what are class 3 edges ?
On 11 August 2007 08:42, Emmanuel Fleury wrote: > Hi, > > Sunzir Deepur wrote: >> >> so why are those class 3 edges created at all ? > > I didn't see any 3-edges blocks at all in your example. Not 3-edge blocks; class 3 edges = the green lines. > These extra edges might come from a non-taken path that have been > removed after some further static-analysis of the code. Sorry, but I > didn't take a deeper look at your example. They appear to be showing where the fall-through path /would have/ gone in those BBs which end with an unconditional jump if there had been no jump. Edge class in the vcg output is determined by the 'class' arg passed by print_rtl_graph_with_bb to the draw_edge routine in graph.c. The only place that generates class 3 edges is the catch-all if (!edge_printed) clause at the end of the for (tmp_rtx) loop. The FOR_EACH_EDGE loop above will output all the 'real' edges that represent possible code flow paths, so it looks to me like gcc is using class 3 as a catch-all for things like EDGE_FAKE, EDGE_CROSSING, and any other of the kinds of edges (basic-block.h) that the compiler maintains for structural reasons that aren't real edges. You'd have to ask someone other than me for the details of what kinds of things other than real edges the compiler stores edge structs for, but that's what ends up being drawn as class 3. cheers, DaveK -- Can't think of a witty .sigline today
Sign extension by expr.c convert_move()
In expr.c, convert_move() tries to synthesize sign extension in modes
larger than those directly supported by the target. There are two strategies
for generating the sign bit copies:
1) Compare with 0 and use "slt" if STORE_FLAG_VALUE == -1.
2) Use a signed right shift of one bit less than the operand width.
/* Compute the value to put in each remaining word. */
if (unsignedp)
fill_value = const0_rtx;
else
{
#ifdef HAVE_slt
if (HAVE_slt
&& insn_data[(int) CODE_FOR_slt].operand[0].mode == word_mode
&& STORE_FLAG_VALUE == -1)
{
emit_cmp_insn (lowfrom, const0_rtx, NE, NULL_RTX,
lowpart_mode, 0);
fill_value = gen_reg_rtx (word_mode);
emit_insn (gen_slt (fill_value));
}
else
#endif
{
fill_value
= expand_shift (RSHIFT_EXPR, lowpart_mode, lowfrom,
size_int (GET_MODE_BITSIZE (lowpart_mode) - 1),
NULL_RTX, 0);
fill_value = convert_to_mode (word_mode, fill_value, 1);
}
}
My questions center around the first aproach:
1) Shouldn't it check that the comparison is directly supported by the
target rather than implemented by a library call? If not, how does it know
that it sets the codition codes? Also, several targets don't emit a
comparison instruction until they know how the result is used. Instead, they
save away the comparison operands. That will fail if the comparison is made
by a library call.
2) How does it handle failure of gen_slt?
I've now hit a case (mulvsi3 on ia16) where it tries to sign extend from
SImode to DImode. It's just that cmpsi2 is implemented as a library call and
gen_slt() fails. Result: "Junk extended" arguments are passed to muldi3.
--
Rask Ingemann Lambertsen
Re: GCC 4.3.0 Status Report (2007-08-09)
Hello, > > Are there any folks out there who have projects for Stage 1 or Stage 2 > > that they are having trouble getting reviewed? Any comments > > re. timing for Stage 3? > > Zadeck has the parloop branch patches, which I've been reviewing. I am > not sure how many other patches are left, but at least a couple. Zdenek > are the remaining patches submitted already? I have one in my review > list, but I don't know if there are others. I could go over them next week. not yet, I just returned from vacation and I should send the remaining two or three patches for the parloop branch merge this week. Zdenek
Announce: VCG support for Graph::Easy
Moin, after being prodded by some people :), I would like to announce a a small project of mine called Graph::Easy to the gcc community (e.g. you :). == Introduction == Graph::Easy is a pure-perl module (GPL) incl. command-line utility to work with graphs and convert them between the various formats. It also contains a (limited) layouter to generate grid-based layouts, which allows to generate pure HTML, ASCII art, boxdrawing art or SVG rendering. In the recent versions, I added support for VCG, which is the language that gcc can dump some information in. This support is still beta, but it should work for most cases now (famous last words :) == Examples == After installing Graph::Easy, here is how you convert a VCG graph to Graphviz, or render it directly as my_vcg_graph.png: graph-easy input.vcg --dot graph-easy my_vcg_graph.vcg --png You can also write Perl scripts and do additional processing on the graph: #!/usr/bin/perl -w use Graph::Easy; use Graph::Easy::Parser::VCG; # input from file my $graph = Graph::Easy::Parser::VCG->from_file( shift ); # ... process stuff here # output to STDOUT print $graph->as_graphviz; Then use this like so: perl my_filter.pl input.vcg >output.dot == Download and Resources == Download Graph::Easy (get at least v0.57!) from CPAN: http://search.cpan.org/~tels/Graph-Easy-0.57/ There are also various resources: http://bloodgate.com/perl/graph/manual/ Online manual http://bloodgate.com/perl/graph/Project page http://bloodgate.com/graph-demo Life demo page == Bugreports == If you encounter any bugs, or missing features, please either email me them directly, or file them on RT: http://rt.cpan.org/NoAuth/ReportBug.html?Queue=Graph-Easy Thank you for your time! :) Hope this is usefull to someone, Tels -- Signed on Sun Aug 12 20:01:02 2007 with key 0x93B84C15. Get one of my photo posters: http://bloodgate.com/posters PGP key on http://bloodgate.com/tels.asc or per email. "Hi, hi, hitotai, space taxi to the sky" pgpX2R94NP9TN.pgp Description: PGP signature
When does this page update ?
http://gcc.gnu.org/gcc-4.2/buildstat.html It seems stuck at 4.2.0 only. If I search around I cna find reports from Joe Buck that seem to help my work but there is nothing linked on the build status page. Dennis Clarke
Re: RFC: Simplify rules for ctz/clz patterns and RTL
I suppose you're using (assuming 32-bit) ctz(x) := 31 - clz(x & -x) now, which gives -1 for 0; and the version you're looking for is ctz(x) := 32 - clz(~x & (x-1)) which gives 32 for 0. (Straight from the venerable PowerPC Compiler Writer's Guide, btw). What does the popcount version look like? Never seen that before, but I think it will be really expensive on PowerPC. Never mind, too trivial, given the second of the above. Segher
