This is the intended behavior, though now I see that the documentation
isn't very clear.
You need to use -fprofile-use - the typical usage scenario is to
compile with -fprofile-generate
to build an executable to do profile collection, and then compile with
-fprofile-use
to build optimized code
On Thu, Jan 8, 2009 at 10:11 AM, Hariharan harihar...@picochip.com wrote:
Hi Seongbae,
Does that mean that someone cant use the profile just to annotate branches
(and get better code by that), without having to get the additional baggage
of unroll-loops, peel-loops etc?
You can do that by
On Mon, Dec 15, 2008 at 2:20 PM, David Meggy david.me...@icron.com wrote:
Hi, I'm working on a very embedded project where we have no operating
system, and there is no window overflow trap handler. I'm really
stretched for memory and I'd like to reduce the stack size. I haven't
not being
On Thu, Mar 13, 2008 at 11:31 AM, Joel Sherrill
[EMAIL PROTECTED] wrote:
Hi,
Moving on the SPARC, I see a lot of similar
unsupported instruction failures. I only
see a single sparc feature test. It is for
-multrasparc -mvis and it is actually
passing on the sparc instruction
2008/3/13 Joel Sherrill [EMAIL PROTECTED]:
Seongbae Park (박성배, 朴成培) wrote:
On Thu, Mar 13, 2008 at 11:31 AM, Joel Sherrill
[EMAIL PROTECTED] wrote:
Hi,
Moving on the SPARC, I see a lot of similar
unsupported instruction failures. I only
see a single sparc feature test
On Thu, Mar 13, 2008 at 12:32 PM, Joel Sherrill
[EMAIL PROTECTED] wrote:
Uros Bizjak wrote:
Hello!
Can someone familiar with VIS provide an instruction
that is OK to do a run-time test with to check if
it is supported?
Perhaps this fragment from
2008/3/1 Andrew Hutchinson [EMAIL PROTECTED]:
I'm am still struggling with a good solution that avoids unneeded saves
of parameter registers.
To solve problem all I need to know are the registers actually used for
parameters. Since the caller assumes all of these are clobbered by
callee
On Wed, Feb 27, 2008 at 5:16 PM, Andrew Hutchinson
[EMAIL PROTECTED] wrote:
Register saves by prolog (pushes) are typically made with reference to
df_regs_ever_live_p() or regs_ever_live. ||
If my understanding is correct, these calls reflect register USEs and
not register DEFs. So if
is not a leaf function (as same register
would be preserved by deeper calls)
Andy
Seongbae Park (박성배, 朴成培) wrote:
On Wed, Feb 27, 2008 at 5:16 PM, Andrew Hutchinson
[EMAIL PROTECTED] wrote:
Register saves by prolog (pushes) are typically made with reference
I think both sides are talking over each other, partially because two
different goals are in mind.
IMHO, there are two extremes when it comes to the so called debugging
optimized code.
One camp wants the full debuggability (let's call them debuggability
crowd) - which means
they want to know the
On 10/24/07, Revital1 Eres [EMAIL PROTECTED] wrote:
Hello,
While testing a patch for the SMS I got an ICE which seems
to be related to the fact we build def-use chains only
and not use-def chains. (removed in the following patch -
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01682.html)
On 10/24/07, Revital1 Eres [EMAIL PROTECTED] wrote:
The problem arises when we delete an insn from the df that contains a
use but do not update the def-use chain of it's def as we do not have
the use-def chain to reach it's def, This later causes a problem when
we try to dump the
Hi Dave,
On x86-64, no regression in 4.2 with the patch.
So both 4.2 and mainline patches are OK.
I'd appreciate it if you can add the testcase
- it's up to you whether to add it in a separate patch or with this patch.
Thanks for fixing it.
Seongbae
On 10/19/07, Seongbae Park (박성배, 朴成培) [EMAIL
On 10/19/07, David Miller [EMAIL PROTECTED] wrote:
From: Seongbae Park (박성배, 朴成培) [EMAIL PROTECTED]
Date: Fri, 19 Oct 2007 17:25:14 -0700
If you're not in a hurry, can you wait
till I run the regtest against 4.2 on x86-64 ?
I've already discussed the patch with Kenny
and we agreed
On 10/19/07, David Miller [EMAIL PROTECTED] wrote:
From: Seongbae Park (박성배, 朴成培) [EMAIL PROTECTED]
Date: Tue, 16 Oct 2007 22:56:49 -0700
Did you replace the DF_REF_REG_USE with DEF ?
If so, that's not correct. We need to add DEF as well as USE:
...
Then, we'll need to change
On 10/14/07, Darryl L. Miles [EMAIL PROTECTED] wrote:
Hello,
On SPARC there is an ABI that is V8+ which allows the linking (and
mixing) of V8 ABI but makes uses of features of 64bit UltraSparc CPUs
(that were not available in the older 32bit only CPUs). Admittedly
looking at the way this
On 10/16/07, David Miller [EMAIL PROTECTED] wrote:
From: David Miller [EMAIL PROTECTED]
Date: Tue, 16 Oct 2007 03:12:23 -0700 (PDT)
I have a bug I'm trying to investigate where, starting in gcc-4.2.x,
the loop invariant pass considers a computation involving a global
register variable as
On 10/16/07, David Miller [EMAIL PROTECTED] wrote:
From: Seongbae Park (박성배, 朴成培) [EMAIL PROTECTED]
Date: Tue, 16 Oct 2007 21:53:37 -0700
Annyoung haseyo, Park-sanseng-nim,
:)
loop-invariant.cc uses ud-chain.
So if there's something wrong with the chain,
it could go nuts.
Can you
On 10/5/07, Hariharan Sandanagobalane [EMAIL PROTECTED] wrote:
Seongbae Park (???, ???) wrote:
On 9/27/07, Hariharan Sandanagobalane [EMAIL PROTECTED] wrote:
Hello,
I am implementing support for PBO on picochip port of GCC (not yet
submitted to mainline).
I see that GCC generates 2
On 9/27/07, Hariharan Sandanagobalane [EMAIL PROTECTED] wrote:
Hello,
I am implementing support for PBO on picochip port of GCC (not yet
submitted to mainline).
I see that GCC generates 2 files, xx.gcno and xx.gcda, containing the
profile information, the former containing the flow graph
On 8/28/07, Zdenek Dvorak [EMAIL PROTECTED] wrote:
...
that obviously is not the case here, though. Do you (or someone else
responsible for df) have time to have a look at this problem?
Otherwise, we may discuss it forever, but we will not get anywhere.
Zdenek
Open a PR and assign it to me,
On 7/30/07, Diego Novillo [EMAIL PROTECTED] wrote:
On 7/27/07 9:58 AM, Zdenek Dvorak wrote:
Hello,
I liked the idea of 'Reviewers' more than any of the other options.
I would like to go with this patch, unless we find a much better
option?
to cancel this category of maintainers
On 7/18/07, Sunzir Deepur [EMAIL PROTECTED] wrote:
Hi list,
Is it ok to assume that when I compile a C file (that is guranteed to have
some code in it) under the following flags, I always get the mentioned
VCG file (and do not get a bigger one) ?
Flags Maximum VCG
On 6/26/07, Steve Ellcey [EMAIL PROTECTED] wrote:
After the dataflow merge (and after doing a couple of other patches that
were needed just to boostrap GCC on IA64 HP-UX), I am still getting some
failures in the GCC testsuite and am hoping for some advise / help on
figuring out what is going on.
On 6/19/07, Rask Ingemann Lambertsen [EMAIL PROTECTED] wrote:
..
Hmm, how do you handle arg_pointer_rtx, frame_pointer_rtx and the like?
The are all uninitialized until the prologue is emitted, which is some time
after reload.
ARG_POINTER_REGNUM is included in the artificial defs of all
On 6/19/07, Sunzir Deepur [EMAIL PROTECTED] wrote:
hello,
when I compile with -dv -fdump-rtl-* I somtimes see in the VCG files
some edges that have no meaning in the flow of the program.
these edges are always green and class 3.
what are those edges ? what is their purposes ?
thank you
sunzir
On 6/16/07, Rask Ingemann Lambertsen [EMAIL PROTECTED] wrote:
I need some help making m68hc11_reorg() work after the dataflow merge, in
particular this bit:
/* Re-create the REG_DEAD notes. These notes are used in the machine
description to use the best assembly directives. */
if
On 6/14/07, Richard Guenther [EMAIL PROTECTED] wrote:
On Wed, 13 Jun 2007, Kenneth Zadeck wrote:
Richard Guenther wrote:
On Tue, 12 Jun 2007, Richard Guenther wrote:
On ia64 SPEC2000 I see fma3d and applu now miscompare.
On x86_64 186.wupwise ICEs with -O2 -ffast-math and FDO:
On 6/12/07, Richard Guenther [EMAIL PROTECTED] wrote:
On Tue, 12 Jun 2007, Richard Guenther wrote:
On ia64 SPEC2000 I see fma3d and applu now miscompare.
On x86_64 186.wupwise ICEs with -O2 -ffast-math and FDO:
/gcc/spec/sb-haydn-fdo-64/x86_64/install-200706120559/bin/gfortran -c -o
zscal.o
Park (박성배, 朴成培) [EMAIL PROTECTED] wrote:
Thanks for the detailed instruction on how to reproduce it
- I have successfully reproduced the problem, and narrowed it down
to combine that's deleting the insn in question.
Hopefully I'll be able to figure out what's wrong soon.
Seongbae
On 6/10/07, Hans
30 matches
Mail list logo
