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

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

[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|                            |avi@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

[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

[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

[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

[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 c/26493] New: -freorder-blocks-and-partition is a dud

[arjanv at redhat dot com]

Gcc puts the section markers incorrect, resulting in a basically dummy effect

Take this simple example:
void simple_test(int X)
{
        if (__builtin_expect((X==3),0))
                call_slowpath_function();
        else
                call_fastpath_function();
}

this leads to the following assembly with 
gcc -O2 -freorder-blocks-and-parittions -s test.c

       .file   "test.c"
        .section        .text.unlikely,"ax",@progbits
.LCOLDB0:
        .text
.LHOTB0:
        .p2align 4,,15
.globl simple_test
        .type   simple_test, @function
simple_test:
.LFB2:
        cmpl    $3, %edi
        je      .L7
        xorl    %eax, %eax
        jmp     call_fastpath_function
.L7:
        xorl    %eax, %eax
        jmp     call_slowpath_function
.LFE2:
        .size   simple_test, .-simple_test
        .section        .text.unlikely
.LCOLDE0:
        .text
.LHOTE0:



as you can see, the .text.unlikely is put after the slowpath code, not when the
slowpath code starts.... which is less than useful.
(it happens for much bigger functions/slowpaths as well so it's not just due to
the small size of the unlikely part here)


-- 
           Summary: -freorder-blocks-and-partition is a dud
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: arjanv at redhat dot com
  GCC host triplet: x86_64-unknown-linux-gnu


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

[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

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

[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

[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

[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

[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