Use -fprofile-generate get basic block counts
Hi, all I want to know every instructions an application runs. So , first , I need to konw every basic blocks' frequency. I'd like to use -fprofile-generate and -fprofile-use get basic block counts. As GCC collect the profile information at pass-tree-profile, I wander whither the instrumentation may restrict some optimization? For example: gcc -fprofile-generate -O3 foo.c -o foo gcc -O3 foo.c -o bar Dose "foo" and "bar" are equally optimized? thanks! -- Jianzhang Peng
Re: Deciding when to sibcall
On Thu, Jan 7, 2010 at 5:29 PM, Dave Korn wrote: > Paulo J. Matos wrote: > >> The problem with this is that I only want to sibcall when it happens >> to reduce my code size. >> >> I noticed (in the internals manual) we cannot actually fallback to a >> normal call once we decide to sibcall through FUNCTION_OK_FOR_SIBCALL, >> however, FUNCTION_OK_FOR_SIBCALL is called during expansion which >> doesn't provide me with as much information as I need to choose >> between sibcalling or not. The best timing would be when the epilogue >> is generated, but this doesn't seem possible. >> >> One example of the kind of information is if some registers are ever >> live. This changes in some cases between the expand pass and the >> pro_and_epilogue pass. As well as the framesize. > > Yep, this takes place during reload which iterates stack frame layout, > reload and spill generation and register elimination until it converges on a > stable solution. > >> All of this >> information is important to have as a precise instrument to decide if >> sibcall should actually be done. >> >> Any suggestion on how to achieve this? > Thanks for the tip. I had thought about heuristic already but I was trying to avoid such a 'non-precise' solution but I guess that's the way I will go If there's no other path. -- Paulo Jorge Matos - pocmatos at gmail.com http://www.pmatos.net
pro_and_epilogue pass ran several time for same function?
Hi all, I just noticed that the pro_and_epilogue pass in gcc3.4.3 for certain functions is ran multiple times with sibcalls enabled. Why is that? What I did was to put a printf on the epilogue and sibcall_epilogue pattern so that during compilation it prints the name of the function currently generating the epilogue for, however, I get a print in epilogue and a print in sibcall_epilogue for the same function a couple of times. Why? Cheers, -- Paulo Jorge Matos - pocmatos at gmail.com http://www.pmatos.net
Re: pro_and_epilogue pass ran several time for same function?
"Paulo J. Matos" writes: > I just noticed that the pro_and_epilogue pass in gcc3.4.3 for certain > functions is ran multiple times with sibcalls enabled. Why is that? > > What I did was to put a printf on the epilogue and sibcall_epilogue > pattern so that during compilation it prints the name of the function > currently generating the epilogue for, however, I get a print in > epilogue and a print in sibcall_epilogue for the same function a > couple of times. Why? One obvious possibility is function cloning, but I can't remember whether gcc 3.4.3 did that. Take a look at the dump file and see whether the function appears more than once. If that doesn't help, run cc1 under a debugger and do a backtrace to find out where the calls are coming from. Ian
Re: pro_and_epilogue pass ran several time for same function?
On Fri, Jan 8, 2010 at 3:34 PM, Ian Lance Taylor wrote:
> "Paulo J. Matos" writes:
>
>> I just noticed that the pro_and_epilogue pass in gcc3.4.3 for certain
>> functions is ran multiple times with sibcalls enabled. Why is that?
>>
>> What I did was to put a printf on the epilogue and sibcall_epilogue
>> pattern so that during compilation it prints the name of the function
>> currently generating the epilogue for, however, I get a print in
>> epilogue and a print in sibcall_epilogue for the same function a
>> couple of times. Why?
>
> One obvious possibility is function cloning, but I can't remember
> whether gcc 3.4.3 did that. Take a look at the dump file and see
> whether the function appears more than once. If that doesn't help,
> run cc1 under a debugger and do a backtrace to find out where the
> calls are coming from.
>
Just checked and it happens with this example:
extern long foo(int *r, int d, long n);
long udiv3232(long n, long d)
{
int q;
if (d < 0)
return foo(0, (int) d, n);
return (long) q;
}
It calls sibcall_epilogue for foo and normal epilogue for returning q,
which is interesting and logic. So, now I am not so surprised.
Thanks,
Paulo Matos
> Ian
>
--
Paulo Jorge Matos - pocmatos at gmail.com
http://www.pmatos.net
errors in example on profile mode libstdc++ (gcc-4.5/changes.html)
In the list of changes for GCC 4.5 there's the following example:
#include
int main()
{
vector v;
for (int k = 0; k > 1024; ++k)
v.insert(v.begin(), k);
}
The declaration of v needs the 'std::' qualification, and the loop
test should use '<' instead of '>'.
Right?
Re: errors in example on profile mode libstdc++ (gcc-4.5/changes.html)
On 01/08/2010 05:00 PM, HyperQuantum wrote: > Right? > Right, fixed. Thanks, Paolo.
