> On Oct 11, 2006, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>
> >> int x; int f() { x = 0;
> >> while(1); }
>
> >> We get line number notes for code only up to "x = 0;".
>
> > I assume this is only a problem when not optimizing.
>
> The opposite, actually. It's optimization that breaks it
Hi,
to give some perspective to the discussion on memory usage, I generated
comparsion of 4.2 branchpoint to 4.3 branchpoint from logs of our memory
tester. I would say it is quite pleasing to see that 4.3 is not really
regression relative 4.2 in most tests like it was custom in previous
releases,
> On 11/4/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
> >Richard Guenther wrote:
> >> On 11/4/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
> >>> Richard Guenther wrote:
> >>> > On 11/4/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
> >>> >> I think that it is time that we in the GCC community too
> Brooks Moses wrote on 11/06/06 17:41:
>
> >Is there a need for any fine-grained control on this knob, though, or
> >would it be sufficient to add an -O4 option that's equivalent to -O3 but
> >with no optimization throttling?
> >
> We need to distinguish two orthogonal issues here: effort and e
Hi,
I know little about CLI, but assuming that your backend is nonstandard
enought so it seems to make sense to replace the RTL bits I guess it
would make sense to make the bb-reorder run on GIMPLE level too, while
keeping bb-reorder on RTL level for common compilation path. This
is example of pas
> Hello,
> CLI back-end uses GIMPLE representation (to be more precise, a subset of
> GIMPLE, the code undergoes a CLI-specific GIMPLE lowering at the end of
> middle-end passes) and just emits bytecode in a CLI-specific assembler
> generation pass.
> Because of that, we (I mean CLI back-end pro
> Hello all,
>
> I'm preparing and testing SMS correction/improvements patch and while
> testing it on the SPU with the vectorizer testcases I've got an ICE in
> the "gcc_assert ( MAX_RECOG_OPERANDS - i)" in function copy_insn_1 in
> emit_rtl.c. The call traces back to the loop versionioning call
> Hi, Jan,
> Thanks for fast response!
>
> I've tested the change you proposed and we still failed in the assert
> checking that the number of SCRATCHes being too large (>30) while
> copying the REG_NOTES of the instruction (see below) using just 9
> SCRATCH registers.
Hi,
apparently there seems
Hi,
thanks for testing. I've bootstrapped/regtested this variant of patch
and comitted it as obvious.
Honza
2006-12-30 Jan Hubicka <[EMAIL PROTECTED]>
Vladimir Yanovsky <[EMAIL PROTECTED]>
* emit-rt.c (emit_copy_of_insn_after): Fix bug ca
Hi,
I do apologize for the breakage, apparently I tested the only target
that didn't break. Andrew's patch seems to be OK for me (as well as the
patch just omitting copy_insn_1 call in the second branch that should
make situation no worse than before my patch and still save the
quadratic memory con
> On Sunday 31 December 2006 00:59, Jan Hubicka wrote:
> > > Also I should mention, this also fixes a possible bug with libcalls that
> > > are embedded in one another. Before we were just assuming if we have a
> > > REG_RETVAL, then the previous REG_LIB
> Hi,
> Sorry for possibly causing confusion. I had tested the patch on my ICE
> testcase and bootstrapped for -enable-languages=C, but didn't run the
> full bootstrap. Bootstrapping the latest Andrew's patch on ppc-linux
> and testing it on SPU.
Vladimir,
I bootstrapped/regtested the patch myself
ChangeLog
===
--- ChangeLog (revision 120315)
+++ ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2007-01-01 Jan Hubicka <[EMAIL PROTECTED]>
+
+ * emit-rtl.c (emit_copy_of_insn_after): Do not call copy_insn_1 for
+ INSN_LIST.
+
2007-01-01 Mike Stump &
Hi,
thanks to Diego, Andrew (MacLeod), Daniel and Roger's effort on
reviewing IPA branch merge patches, I hope to commit after re-testing
the patch to enable IPA-SSA today. This means that the main part of
IPA-branch has been merged. There are still features on IPA branch that
I hope to follow sho
onder why the
bootstrap doesn't fail on all targets?
Honza
Index: ChangeLog
===
*** ChangeLog (revision 120588)
--- ChangeLog (working copy)
***
*** 1,3
--- 1,7
+ 2007-01-08 Jan Hubicka <[EMAIL PROTECTED]>
+
+ * tree-vectorizer.c (gate_in
it tomorrow.
Hope that all bootstraps are fine now!
Index: ChangeLog
===
--- ChangeLog (revision 120589)
+++ ChangeLog (working copy)
@@ -1,6 +1,7 @@
2007-01-08 Jan Hubicka <[EMAIL PROTECTED]>
* tree-
> I am pleased to announce that the GCC Steering Committee has
> appointed Jan Hubicka and Uros Bizjak as co-maintainers of the i386 port.
>
> Please join me in congratulating Jan and Uros on their new role.
> Jan and Uros, please update your listings in the MAINTAINE
> I know Andrew replied privately, but I hope he doesn't mind me raising
> the issue on-list. I just wanted to guage the general feeling as to
> whether I'd screwed up, and whether I should have submitted the patches
> in a different way.
I guess one should rather thank you for taking time to spl
> Hello,
>
> > > > GCC trunk revision 120704 failed to build SPEC cpu2000/gcc on -O1 and
> > > > higher optimization level at x86_64-redhat-linux.
> > > >
> > > > reload1.c: In function 'reload':
> > > > reload1.c:449: error: address taken, but ADDRESSABLE bit not set
> > > > bad_spill_regs
> >
> On 1/28/07, tbp <[EMAIL PROTECTED]> wrote:
> >Let it be clear from the start this is a potshot and while those
> >trends aren't exactly new or specific to my code, i haven't tried to
> >provide anything but specific data from one of my app, on
> >win32/cygwin.
> >
> >Primo, gcc getting much bette
> On 1/28/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
> >On 1/28/07, tbp <[EMAIL PROTECTED]> wrote:
> >> objdump -wdrfC --no-show-raw-insn $1|perl -pe 's/^\s+\w+:\s+//'|perl
> >> -ne 'printf "%4d\n", hex($1) if /sub\s+\$(0x\w+),%esp/'|sort -r| head
> >> -n 10
> >>
> >> msvc:2196 2100 1772 1692
> On 1/28/07, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> >Also having some testcases showing inlining deffects in GCC would be
> >very interesting for me. Now after IPA-SSA has been merged, I plan to
> >do some retuning of inliner for 4.3 release since a lot has changes
> tbp wrote:
>
> > Secundo, while i very much appreciate the brand new string ops, it
> > seems that on ia32 some array initialization cases where left out,
> > hence i still see oodles of 'movl $0x0' when generating code for k8.
> > Also those zeroings get coalesced at the top of functions on ia3
> Jan Hubicka wrote:
>
> > I though the comment was more reffering to fact that we will happily
> > generate
> > movl $0x0, place1
> > movl $0x0, place2
> > ...
> > movl $0x0, placeMillion
> >
> > rather than shorter
> > xor %eax, %e
> On 1/28/07, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> >I am not quite sure what you mean by direct inlining here. At -O2 G++
> Decorating everything in sight with attribute always_inline/noinline
> (flatten wasn't an option because it used to be troublesome and
>
> Hi,
>
> currently with -ftree-vectorize we generate for
>
> for (i=0; i<3; ++i)
> # SFT.4346_507 = VDEF
> # SFT.4347_508 = VDEF
> # SFT.4348_509 = VDEF
> d[i] = 0.0;
Also Tomas' patch is supposed to catch this special case and convert it
into memset that should be subsequentl
> Richard Guenther <[EMAIL PROTECTED]> wrote on 05/02/2007 18:16:05:
>
> > On Mon, 5 Feb 2007, Jan Hubicka wrote:
> ...
> > > Did you run some benchmarks?
> >
> > Not yet - I'm looking at the C++ SPEC 2006 benchmarks at the moment
> > and usin
> In an OS kernel functions that do not return are commonly used and
> practically always their code is beyond gcc's ability to recognize
> noreturn functions. A typical example would for example be the BUG()
> function in Linux which is implemented as something like:
>
> static inline void __att
> Dear All,
>
>In order to implement a specific basic block profiling, i have to
> insert function calls at the end of each basic blocks or/and at the end
> of each functions.
> To do this I'd like to add a profiling pass similar to the arc profiling.
> I'm a beginner in the GCC internal imp
>
> >Would you for a start please
> >explain what do you need to do that can't be done using existing arc and
> >value profiling?
> >
> Sorry, my first mail was not clear about the goal.
> Objectives are to follow the execution of function and basic block at
> execution time.
> To do this, we p
> ?? wrote:
> >Now, my question becomes clear. How to make my inserted function call
> >not affect the orginal state of program?
>
> Try looking at a similar feature. One such similar feature is the
> mcount calls emitted for profiling. The various solutions for mcount
> include
> 1) savin
> I just got this error building a cross-compiler from sparc-sun-solaris2.10
> targetted to i686-unknown-linux-gnu. This worked as recently as last
> week:
>
> > build/genoutput ../../egcc-SVN20070216/gcc/config/i386/i386.md
> insn-conditions.md > tmp-output.c
> > config/i386/i386.md:3705: err
> Grigory Zagorodnev wrote:
> > Mark Mitchell wrote:
> >> Excellent question; I should have asked for that as well. If 4.2 has
> >> gained on 4.1 in other respects, the 4.7% drop might represent a smaller
> >> regression relative to 4.1.
> >>
> > There is the 4.2 (r120817) vs. 4.1.2 release FP per
>
> Why do we use 256 instead of BIGGEST ALIGNMENT in ix86_data_alignment?
> This is causing all sorts of build problems for djgpp, as I'm getting
> lots of warnings about too-big alignments, and with -Werror...
It is to improve performance of string functions on larger chunks of
data. x86-64 sp
>
> > > I like the "min (256, MAX_OFILE_ALIGNMENT)" fix...
> >
> > So do I.
>
> Ok to apply then? Tested via djgpp cross-compile and cross-host.
Yes, this is OK. (to be very pedantic, we can assert that
MAX_OFILE_ALIGNMENT>=256 on x86-64 targets, but well). I fully agree with
Richard's interpr
> >
> > > > I like the "min (256, MAX_OFILE_ALIGNMENT)" fix...
> > >
> > > So do I.
> >
> > Ok to apply then? Tested via djgpp cross-compile and cross-host.
>
> Yes, this is OK. (to be very pedantic, we can assert that
> MAX_OFILE_ALIGNMENT>=256 on x86-64 targets, but well). I fully agree with
> "Vladimir N. Makarov" <[EMAIL PROTECTED]> writes:
>
> > I run SPEC2000 several times per week and always look at 3 runs (to be
> > sure that is nothing wrong happened) but I never saw such big
> > "confidence" intervals (as I understand that is difference between max
> > and min of 3 runs divide
> Jan Hubicka wrote:
>
> >I am running SPEC on both AMD and Intel machines quite commonly and I
> >must say that there seems to be difference in between those two. For P4
> >and Core I get results within something like 1-2 SPEC point (0.1%) of
> >overall
> &g
> Grigory Zagorodnev wrote on 03/03/07 02:27:
>
> > There are three checkins, candidates for the root of regression:
> > http://gcc.gnu.org/viewcvs?view=rev&revision=122487
> > http://gcc.gnu.org/viewcvs?view=rev&revision=122484
> > http://gcc.gnu.org/viewcvs?view=rev&revision=122479
>
> I think something like
>
> struct gimple_statment_base
> {
> enum gimple_stmt_code code : 8;
> unsigned int subcode : 24;
> source_locus locus;
> tree block;
Just jumping late into the debug info discussion, RTL locators are
combining TREE blocks and source_locuses into sing
>
> I have added the design document and links to most of the discussions
> we've had so far. Aldy updated the document to reflect the latest thread.
>
> http://gcc.gnu.org/wiki/tuples
Looks great, still I think "locus" and "block" could be both merged into
single integer, like RTL land has INS
> Jan Hubicka wrote on 04/14/07 16:14:
>
> > Looks great, still I think "locus" and "block" could be both merged into
> > single integer, like RTL land has INSN_LOCATOR.
>
> That's the idea. But it's simpler to do this for now. T
> Jan Hubicka wrote on 04/14/07 21:14:
>
> > I just wondered if your document is documenting the final shape or what
> > should be done during hte first transition. If the second, probably 2
> > words should be accounted for location as source_locues is currently a
> PRE is only using stmt_ann->uid as a convenient place to store the uid
> for local dominance for purposes of Load PRE.
> It's making up the UID on it's own :).
>
> If there was stmt->aux we'd put it there instead (note that the
> current way wastes memory, since we really only care about UID's f
Hi,
> Hello all,
>
> I'm doing in my IPA pass:
> for(node = cgraph_nodes; node; node = node->next) {
>reg_cgraph_node(IDENTIFIER_POINTER(DECL_ASSEMBLER_NAME(node->decl)));
> }
>
> to get all the function names in the cgraph. I'm adding them to a list
> and I'm assuming that two nodes do not h
> On 4/16/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote:
> >Hello all,
> >
> >I'm going through the bodies of all user-defined functions. I'm using
> >as user-defined function as one that:
> >DECL_BUILT_IN(node) == 0.
>
> >
> >Problem is that for a function (derived from a C++ file) whose output
>
> On 4/16/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> >
> >First, it's not built in, because it's defined in a source file.
> >Builtin functions are those defined by the compiler.
> >
> >Second, we should make FOR_EACH_BB_FN never crash on empty tree functions.
> >It seems really rude to do othe
> On 4/16/07, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> >Hi,
> >> Hello all,
> >>
> >> I'm doing in my IPA pass:
> >> for(node = cgraph_nodes; node; node = node->next) {
> >>reg_cgraph_node(IDENTIFIER_POINTER(DECL_ASSEMBLER_N
>
> If you just want to scan every function you have around, the obvious
> way to do it is
>
> For each function
> FOR_EACH_BB_FN (function).
>
> This is probably slightly slower than
>
> For each function
> if cgraph_function_body_availability != NOT_AVAILABLE
>FOR_EACH_BB_FN (function)
> > Look from what we're starting:
> >
> > <<
> > @item -funroll-loops
> > @opindex funroll-loops
> > Unroll loops whose number of iterations can be determined at compile
> > time or upon entry to the loop. @option{-funroll-loops} implies
> > @option{-frerun-cse-after-loop}. This option makes co
> On Sun, 2007-04-22 at 14:44 +0200, Richard Guenther wrote:
> > On 4/22/07, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
> > > > > but also does not make anyone actually use the options. Nobody reads
> > > > > the documention. Of course, this is a bit overstatement, but with a
> > > > > few excepti
> On 4/23/07, Paul Richard Thomas <[EMAIL PROTECTED]> wrote:
> >on x86_ia64/fc5 is not a coincidence?
>
> More over, there were a lot of targets by this patch because they
> would call insn_locators_initialize when generating the thunks (x86
> did not because it uses text based thunks and not RTL
>
> I'd rather remove this "hack" and use the inliners code size estimator, like
> that patch from early 2005 (attached)...
Uh yes, I think it is way to go (and additionally making -O2 to
autoinline small functions like -Os does).
The patch would be OK if it still works ;) Even if CSiBE regress
> On Monday 28 February 2005 10:25, Richard Guenther wrote:
> > > I can only wonder why we are having this discussion just after GCC 4.0
> > > was branched, while it was obvious already two years ago that inlining
> > > heuristics were going to be a difficult item with tree-ssa.
> >
> > There were
> On Tuesday 01 March 2005 01:33, Jan Hubicka wrote:
> > > On Monday 28 February 2005 10:25, Richard Guenther wrote:
> > > > > I can only wonder why we are having this discussion just after GCC
> > > > > 4.0 was branched, while it was obvious alr
> On Tue, 1 Mar 2005 02:03:57 +0100, Jan Hubicka <[EMAIL PROTECTED]> wrote:
>
> > OK, I will put this higher in the TODO list (but this is not 4.0
> > either). What was those less unrealistic tests? I remember seeing node
> > removal in profiles, but edge removal c
> On Tue, 1 Mar 2005 13:30:41 +0100, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> > > On Tue, 1 Mar 2005 02:03:57 +0100, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> > >
> > > > OK, I will put this higher in the TODO list (but this is not 4.0
> > >
Hi,
so after reading the whole discussion, here are some of my toughts
for sanity check combined in one to reduce inbox pollution ;)
Concerning Richard's cost tweaks:
There is longer story why I like it ;)
I originally considered further tweaking of cost function as mostly lost
case as the repres
> On Tue, 1 Mar 2005 16:49:04 +0100, Richard Guenther
> <[EMAIL PROTECTED]> wrote:
> > On Tue, 1 Mar 2005 16:14:14 +0100, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> >
> > > Concerning growth limits:
> > >
> > > If you take a look on when -
Hi,
I did merge to tree profiling yesterday and committing to the tree
didn't went correctly, so tree was messed up till today. So if
something breaks for you, please just update and hopefully everything
will be OK now.
Honza
> On Wednesday 30 March 2005 05:27, Gerold Jury wrote:
> >
> > >> On Tue, Mar 29, 2005 at 05:37:06PM +0300, Denis Vlasenko wrote:
> > >> > /*
> > >> > * This looks horribly ugly, but the compiler can optimize it totally,
> > >> > * as the count is constant.
> > >> > */
> > >> > static inline vo
> Hi,
>
> We would like to know if there is some way to find the true and false
> branches of a conditional jump in RTL. In the tree CFG, we have two
> edge flags for that, EDGE_{TRUE,FALSE}_VALUE, but those flags have no
> meaning for the RTL CFG. So our question is, is there some other way
> t
> That might be related to the bootstrap failure on AIX as well.
Hopefully this is fixed now by Jeff's patch.
>
> Also, the commit modified files not listed in the ChangeLog:
>
> gcc/tree-pass.h
> gcc/cp/method.c
>
> adding function tree_lowering_passes()
Uhm, I apparently cut&paste
> >>>>> Jan Hubicka writes:
>
> >> That might be related to the bootstrap failure on AIX as well.
>
> Jan> Hopefully this is fixed now by Jeff's patch.
>
> The libjava failure is fixed, but the patch will not affect the
> AIX libgfortra
> >>>>> Jan Hubicka writes:
>
> >> That might be related to the bootstrap failure on AIX as well.
>
> Jan> Hopefully this is fixed now by Jeff's patch.
>
> The libjava failure is fixed, but the patch will not affect the
> AIX libgfortra
> Hi,
>
> I am observing a bootstrap failure for the avr target that seems to be
> related
> to the patch
>
> 2005-05-19 Jan Hubicka <[EMAIL PROTECTED]>
> ...
> * basic-block.h (REG_BR_PROB_BASE): Define.
> ...
> * rtl.h (REG_BR_PROB_
> >
> > Since the missing macros seem to have moved from rtl.h to basic-block.h,
> > I'd
> > like to know at which place one would need gcc make include the additional
> > header. IIUC, instruction-emit.c is the machine-generated source file that
> > is
> > generated by the machine-descriptio
> On Fri, May 20, 2005 at 07:41:53PM +0200, Jan Hubicka wrote:
> > I am looking into that now. I would preffer the way of adding
> > basic-block.h and friends into includes of insn-emit.c as in general I
> > would like to make expanders/splitters/output templates aware of
> On Sat, May 21, 2005 at 09:08:45AM +0200, Eric Botcazou wrote:
> > Are these specific to SPARC?
>
> No.
I believe Andrew mentioned that there is a patch for this? (it is lack
of sync in between operands and stmt itself)
Honza
>
>
> r~
> On Sat, May 21, 2005 at 09:45:38PM +0200, Eric Botcazou wrote:
> > Btw, is it me or the individual RTL dump options are broken?
>
> The initial rtl dump is broken. The rest work.
>
> I think one of Jan's IPA pass manager changes broke it.
What are the symptoms? -fdump-tree-expand seems to wo
> On Sunday 22 May 2005 00:16, Jan Hubicka wrote:
> > (not sure of -fdump-rtl-expand ever worked, but I
> > might try to restore it if it did).
>
> It very definitely did work, and quite nicely too.
> Try -fdump-rtl-expand-details.
Yeah, but on tree-profiling it alway
> Hello!
>
> > Well you really want both the fpcr and the mxcsr registers, since the fpcr
> > only controls the x87 and the mxcsr controls the xmm registers. Note, in
> > adding these registers, you are going to have to go through all of the
> > floating
> > point patterns to add (use:HI FPCR_RE
> First off, is anyone working on providing GCC or libm with a (complete)
> set of C99 math functions with SSE/SSE2 calling conventions? If not, I
> will start with something like the following plan:
>
> 1. There is already support for switching the ABI function-wise in
> the backend for loc
> Hello,
>
> I'm seeing compiler crashes during garbage collection when using mudflap.
>
> The problem appears to be that some basic_block_def structures point to
> edge_prediction structures which point to edge_def structures that have
> already been ggc_free()'d.
>
> Now, looking at remove_edg
> Jan Hubicka wrote:
>
> > I didn't have any cleanup_cfg in between earliest place putting
> > predictions and the profiling pass consuming them, so this scenario
> > didn't happen. This has however changed a long time ago. I guess just
> > teaching remo
> Jan Hubicka wrote:
>
> > I've comitted the attached patch. I didn't suceed to reproduce your
> > failures, but Danny reported it fixes his and it bootstrap/regtests
> > i686-pc-gnu-linux.
>
> Thanks; this does fix one crash on s390x, but doesn
> Hello!
>
> There is an interesting comparison of SPEC scores between gcc and icc:
> http://people.redhat.com/dnovillo/spec2000.i686/gcc/individual-run-ratio.html
> . A quick look at the graphs shows a big differences in achieved scores
> between gcc and icc, mostly in SpecFP tests. I was tryi
> On Mon, Jun 13, 2005 at 07:17:24PM -0700, Zack Weinberg wrote:
> > Or, if GAS can be told which mode it should be in via directives in
> > its input (.code32/.code64?), then we could add something like
> >
> > fputs (TARGET_64BIT ? "\t.code64\n" : "\t.code32",
> > asm_out_file);
> >
>
> Richard Henderson <[EMAIL PROTECTED]> writes:
>
> > On Mon, Jun 13, 2005 at 07:17:24PM -0700, Zack Weinberg wrote:
> >> Or, if GAS can be told which mode it should be in via directives in
> >> its input (.code32/.code64?), then we could add something like
> >>
> >> fputs (TARGET_64BIT ? "\t.co
ion 2.9161
> diff -u -r2.9159 -r2.9161
> --- ChangeLog 15 Jun 2005 20:13:04 - 2.9159
> +++ ChangeLog 16 Jun 2005 10:31:51 - 2.9161
> @@ -1,3 +1,59 @@
> +2005-06-16 Jan Hubicka <[EMAIL PROTECTED]>
> +
> + * basic-block.h (rtl_bb_info): Break out h
> stage1/xgcc -Bstage1/
> -B/home/guerby/work/gcc/install/install-20050616T132922/i686-pc-linux-gnu/bin/
> -c -O2 -g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings
> -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
> -Wno-variadic-macros -Wold-style-definition -Werr
> On Friday 17 June 2005 08:30, Steve Kargl wrote:
> > On Fri, Jun 17, 2005 at 08:01:47AM +0200, FX Coudert wrote:
> > > Jerry DeLisle wrote:
> > > >There appears to be numerous regression failures this evening. I
> > > >suppose these are back end related.
> > >
> > > On i686-freebsd, i386-linux a
> Honza,
>
> Your patch here: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00976.html
> has left a number of fortran test cases broken (e.g. gfortran.dg/select_2).
>
> The problem seems to be that you used the aux field as a replacement for
> rbi->copy_number, but tree_verify_flow_info assumes au
> I get this error compiling linux-2.6.11.3 with gcc-4.1-20050702 on many
> targets:
>
> drivers/char/random.c: In function 'extract_entropy':
> drivers/char/random.c:634: sorry, unimplemented: inlining failed in call to
> 'add_entropy_words': function not considered for inlining
> drivers/char/
> Hi,
>
> I am trying to profile the frequency of each basic block of
> SPEC 2000 benchmarks by compiling them using -fprofile-arcs and opt -O3.
> After running the benchmark, when I try to read "bb->count" while
> compiling
> using "-fbranch-probabilities and -O3", I get "0" values for basic bl
oll-times=0 a.c".
> During this phase, I try to obtain dynamic frequencies of the statements
> within the "for"
> loop in "foo" method at RTL level. The frequencies return "0" using
> "bb->count". I
> would like this to reflect &q
> On Wed, Jul 20, 2005 at 10:45:01AM -0700, girish vaitheeswaran wrote:
> > > --- Steven Bosscher <[EMAIL PROTECTED]> wrote:
> > >
> > > > On Wednesday 20 July 2005 18:53, girish vaitheeswaran wrote:
> > > > > I am seeing a 20% slowdown with feedback optimization.
> > > > > Does anyone have any th
obably better to just turn off the individual
optimizations with -fprofile-use (for optimizations that are implied by
this flag there should be no need to re-profile each time).
If you can find particular optimization that gets out of control, it
would be lot easier to fix it...
Honza
> trials
t is gong wrong?
Thanks,
Honza
>
> Can someone help me out on how to proceed with this.
>
> Thanks
> -girish
>
>
> --- Jan Hubicka <[EMAIL PROTECTED]> wrote:
>
> > > I started with a clean slate in my build
> > environment
> > > and did
o proceed from here is some profiling.
The way I usually look into such problems is to produce oprofile of both
versions of code and then compare the times spent in individual
functions then it is sometimes possible to identify the offending code
more easilly
Honza
> Thx
> -girish
>
Hi,
I've branches the IPA branch yesterday and re-directed current SPEC
testers running tree-profiling branch (now officially retired ;) to it.
( http://www.suse.de/~aj/SPEC/amd64 ).
The branch should be used for interprocedural optimization projects that
has serious chance to get into 4.2 (or perh
> Hi,
> I've branches the IPA branch yesterday and re-directed current SPEC
> testers running tree-profiling branch (now officially retired ;) to it.
> ( http://www.suse.de/~aj/SPEC/amd64 ).
> The branch should be used for interprocedural optimization projects that
> has serious chance to get into
> On Thursday 04 August 2005 19:12, Jan Hubicka wrote:
> > > Hi,
> > > I've branches the IPA branch yesterday and re-directed current SPEC
> > > testers running tree-profiling branch (now officially retired ;) to it.
> > > ( http://www.suse.de/~aj/SPEC/
> On Saturday 06 August 2005 08:14, Andrew Pinski wrote:
> > On Aug 5, 2005, at 9:24 PM, Canqun Yang wrote:
> > > Hi,
> > >
> > > Patch from Michael Matz
> > > (http://gcc.gnu.org/ml/fortran/2005-07/msg00331.html) may partly fixes
> > > the multiple decls problems.
> >
> > That will only help with
>
> Hi Jan,
>
> Your patch to mainline
>
> http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg00388.html
>
> to defer handling of local statics has caused a regression
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22034
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22583
> http:
> On Aug 12, 2005, at 5:05 AM, Etienne Lorrain wrote:
> > I have added a command to the linker file to forbid reference from
> > one section to another:
> >NOCROSSREFS (.text .xcode);
>
> It sounds like this feature isn't compatible with inlining, -fno-
> inline I suspect is one of the few ways
> > "Mike" == Mike Stump <[EMAIL PROTECTED]> writes:
>
> Mike> On Aug 12, 2005, at 10:39 AM, Dale Johannesen wrote:
> >> We had a situation come up here where things are like this
> >> (simplified, obviously):
> >>
> >> c() { char x[100]; }
>
> Mike> I think we should turn off inli
>
> There was some discussion a few weeks ago about some apps running slower
> with FDO enabled.
>
> I've recently investigated a similar situation using mainline. In my case,
> the fact that the loop_optimize pass is disabled during FDO was the cause
> of the slowdown. It appears that was rece
> >you may try adding -fmove-loop-invariants flag, which enables new
> >invariant motion pass.
>
> That cleaned up both my simplified test case, and the code it
> originated from. It also cleaned up a few other cases where I
> was noticing worse performance with FDO enabled. Thanks!!
>
> Perhap
> Hi Jan,
>
> I think fixup_reorder_chain contains questionable code to cope with a
> pathological case:
>
> /* The degenerated case of conditional jump jumping to the next
>instruction can happen on target having jumps with side
>effects.
>
>
1 - 100 of 681 matches
Mail list logo
