[Bug rtl-optimization/26493] -freorder-blocks-and-partition is a dud without generated profiling data

2017-06-08 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26493

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from Andrew Pinski  ---
Fixed for GCC 8:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=32b3df079a3af3933c2b137cb1f772e96ca9499d

[Bug rtl-optimization/26493] -freorder-blocks-and-partition is a dud without generated profiling data

2013-12-30 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26493

Andrew Pinski pinskia at gcc dot gnu.org changed:

   What|Removed |Added

 CC||a...@cloudius-systems.com

--- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org ---
*** Bug 59639 has been marked as a duplicate of this bug. ***


[Bug rtl-optimization/26493] -freorder-blocks-and-partition is a dud without generated profiling data

2013-12-30 Thread mkgnu at mkgnu dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26493

--- Comment #9 from Kristis Makris mkgnu at mkgnu dot net ---
I won't see, open or read your email.
I won't even know you emailed me.


If there's something you want me to do you have to use this:
https://aimelia.com/res?id=CZPr9mKgQTQfD3dYqy00b5qg


This is an automated response.


[Bug rtl-optimization/26493] -freorder-blocks-and-partition is a dud without generated profiling data

2013-12-30 Thread mkgnu at mkgnu dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26493

--- Comment #10 from Kristis Makris mkgnu at mkgnu dot net ---
I won't see, open or read your email.
I won't even know you emailed me.


If there's something you want me to do you have to use this:
https://aimelia.com/res?id=BJ6WQBHg1LEYvkwLH6Hn02hK


This is an automated response.


[Bug rtl-optimization/26493] -freorder-blocks-and-partition is a dud without generated profiling data

2013-12-30 Thread mkgnu at mkgnu dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26493

--- Comment #11 from Kristis Makris mkgnu at mkgnu dot net ---
I won't see, open or read your email.
I won't even know you emailed me.


If there's something you want me to do you have to use this:
https://aimelia.com/res?id=wnVviP0qSkNXW1mtSIOKtdq5


This is an automated response.


[Bug rtl-optimization/26493] -freorder-blocks-and-partition is a dud without generated profiling data

2013-12-30 Thread mkgnu at mkgnu dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26493

--- Comment #12 from Kristis Makris mkgnu at mkgnu dot net ---
Please revise and resubmit. I can't tell clearly why whatever it is you are
asking is important.


[Bug rtl-optimization/26493] -freorder-blocks-and-partition is a dud without generated profiling data

2007-04-30 Thread mkgnu at mkgnu dot net


--- Comment #6 from mkgnu at mkgnu dot net  2007-04-30 23:42 ---
It seems that when I use -freorder-blocks-and-partition along with
-fprofile-use (after I have already run once an executable compiled with
-freorder-blocks-and-partition -fprofile-generate) I can produce an object file
that contains a .text.unlikely section, as expected.

But when I try to further link this object file with other object files to
produce an executable, the .text.unlikely section is missing from the final
executable. I've tried this with gcc4.1.2/ld2.15 and then again with
gcc4.1.1/ld2.17 with the same results.

Is this another bug related to -freorder-blocks-and-partition ? Should I file a
separate bug report for it ?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26493



[Bug rtl-optimization/26493] -freorder-blocks-and-partition is a dud without generated profiling data

2007-04-30 Thread pinskia at gcc dot gnu dot org


--- Comment #7 from pinskia at gcc dot gnu dot org  2007-04-30 23:48 ---
(In reply to comment #6) 
 But when I try to further link this object file with other object files to
 produce an executable, the .text.unlikely section is missing from the final
 executable. I've tried this with gcc4.1.2/ld2.15 and then again with
 gcc4.1.1/ld2.17 with the same results.

What do you mean by missing?  The default linker scripts combines .text.* into
.text (but puts together those sections first).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26493



[Bug rtl-optimization/26493] -freorder-blocks-and-partition is a dud without generated profiling data

2007-04-24 Thread pinskia at gcc dot gnu dot org


--- Comment #4 from pinskia at gcc dot gnu dot org  2007-04-24 20:27 ---
*** Bug 31689 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||mkgnu at mkgnu dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26493



[Bug rtl-optimization/26493] -freorder-blocks-and-partition is a dud without generated profiling data

2007-04-24 Thread mkgnu at mkgnu dot net


--- Comment #5 from mkgnu at mkgnu dot net  2007-04-25 02:12 ---
(In reply to comment #3)
 I've tried a couple of different ways to use branch predictions for
 partitioning, but it never leads to meaningful results.  Either everything is
 hot or everything is cold.  I don't know what else to do about this.

Steven, perhaps you could elaborate what you mean by saying it never leads to
meaningful results ?

 I'm actually tempted to claim this is a WONTFIX because hot and cold are
 not meaningful without profile information.  Thoughts, anyone?

I'm working on a research prototype in which I produce code that should be cold
for a considerable amount of time when a program runs. After some time (or
perhaps never), when a flag is raised, we'd like to use the cold code just
once, and then revert the program back to it's original behavior of running
only hot code.

Apparently, as bug 31689 shows, I need this feature. In this research prototype
I am 100% certain that a piece of code will be cold -- there's no need to
gather profiling information, and I absolutely need this code to be out of the
.text section.

Using this research prototype, I ran experiments that demonstrate a slowdown in
computation-bound applications in the range of 4%-300% on the i386 and PowerPC
architectures depending on the size of the processor i-cache. I believe that
moving the cold code sections out of .text will bring the overhead down to less
than 4%, constantly.

I absolutely, positively, definitely find value in this feature. In fact, my
research progress depends on it and I am actively looking for a way to have
this implemented.

Can you help ?

I've tried using __builtin_expect() and -freorder-blocks-and-partition with gcc
4.1.2 and it doesn't seem to work. If there's a patch laying around that
implements this feature without gathering profiling information I would love to
try it out immediately.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26493



[Bug rtl-optimization/26493] -freorder-blocks-and-partition is a dud without generated profiling data

2007-04-13 Thread steven at gcc dot gnu dot org


--- Comment #3 from steven at gcc dot gnu dot org  2007-04-13 22:41 ---
I've tried a couple of different ways to use branch predictions for
partitioning, but it never leads to meaningful results.  Either everything is
hot or everything is cold.  I don't know what else to do about this.

I'm actually tempted to claim this is a WONTFIX because hot and cold are
not meaningful without profile information.  Thoughts, anyone?


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|steven at gcc dot gnu dot   |unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26493