[PATCH i386] Enable -freorder-blocks-and-partition

[Teresa Johnson]

On Wed, Dec 11, 2013 at 1:21 AM, Martin Liška <marxin.liska@gmail.com> wrote:
> Hello,
>    I prepared a collection of systemtap graphs for GIMP.
>
> 1) just my profile-based function reordering: 550 pages
> 2) just -freorder-blocks-and-partitions: 646 pages
> 3) just -fno-reorder-blocks-and-partitions: 638 pages
>
> Please see attached data.

Thanks for the data. A few observations/questions:

With both 1) (your (time-based?) reordering) and 2)
(-freorder-blocks-and-partitions) there are a fair amount of accesses
out of the cold section. I'm not seeing so many accesses out of the
cold section in the apps I am looking at with splitting enabled. In
the case of splitting, it could either be non-representative profile
data or profile data that isn't being maintained properly and lost,
although I think I fixed most of those. If you have identified any of
the cold split routines that are being executed in the case of 2) it
would be interesting to look at the dumps.

With 2) there is also a big clump towards the end which is being
executed out of the cold section, which again would be interesting to
investigate.

Why is your function reordering in 1) accessing more out of the cold
section than 3) (-fno-reorder-blocks-and-partitions)?

Both 2) and 3) have both normal .text and .text.hot, whereas 1) only
has .text. I wonder if that is contributing to the higher number of
pages either of these has compared to 1), since the non-cold addresses
are distributed across both sections?

Teresa


>
> Martin
>
> On 2 December 2013 17:52, Martin Liška <marxin.liska@gmail.com> wrote:
>> Dear Teresa,
>>    I will today double check if the graphs are correct :)
>>
>> Martin
>>
>> On 2 December 2013 17:16, Jeff Law <law@redhat.com> wrote:
>>> On 12/02/13 08:16, Teresa Johnson wrote:
>>>>
>>>>
>>>> I'm wondering if the -fno-reorder-blocks-and-partition graph really
>>>> had that disabled. I am surprised that the size of the .text and
>>>> .text.hot did not shrink from splitting.
>>>
>>> Could be due to needing longer jump opcodes to reach the unlikely sections.
>>> jeff
>>>



-- 
Teresa Johnson | Software Engineer | tejohnson@google.com | 408-460-2413