On Sat, May 11, 2013 at 4:38 PM, Teresa Johnson wrote:
> /* If we are partitioning hot/cold basic blocks, we don't want to
> mess up unconditional or indirect jumps that cross between hot
> and cold sections.
>
> Basic block partitioning may result in some jumps that appear to
>
On Sat, May 11, 2013 at 4:19 AM, Jan Hubicka wrote:
>> >
>> > BTW2: We badly need to figure out a way to create test cases for FDO... :-(
>>
>> Yes. I had tried testing awhile back with the gcc regression tests and
>> enabling -freorder-blocks-and-partition, but none of the issues I was
>> having
On Sat, May 11, 2013 at 4:44 AM, Steven Bosscher wrote:
> On Sat, May 11, 2013 at 5:21 AM, Teresa Johnson wrote:
>> Here there was a block that happened to be laid out at the very start
>> of the cold section (it was jumped to from elsewhere, not reached via
>> fall through from its layout predece
> On Sat, May 11, 2013 at 1:19 PM, Jan Hubicka wrote:
> > Once -freorder-blocks-and-partition actually works, we should enable it by
> > default with -fprofile-generate (I recall I was trying to do that once, but
> > I am not sure what was outcome back then and why it did not happen).
> > That shou
On Sat, May 11, 2013 at 1:19 PM, Jan Hubicka wrote:
> Once -freorder-blocks-and-partition actually works, we should enable it by
> default with -fprofile-generate (I recall I was trying to do that once, but
> I am not sure what was outcome back then and why it did not happen).
> That should get it
On Sat, May 11, 2013 at 5:21 AM, Teresa Johnson wrote:
> Here there was a block that happened to be laid out at the very start
> of the cold section (it was jumped to from elsewhere, not reached via
> fall through from its layout predecessor). Thus it was preceded by a
> switch section note, which
> >
> > BTW2: We badly need to figure out a way to create test cases for FDO... :-(
>
> Yes. I had tried testing awhile back with the gcc regression tests and
> enabling -freorder-blocks-and-partition, but none of the issues I was
> having with larger benchmarks fired. I think there just aren't en
On Fri, May 10, 2013 at 2:00 PM, Steven Bosscher wrote:
> On Fri, May 10, 2013 at 5:54 PM, Teresa Johnson wrote:
>> The main issue I had here, and why I made this change, is that we go
>> in and out of cfglayout mode several times after bb partitioning and
>> then out_of_cfglayout. The problem was
On Fri, May 10, 2013 at 11:10 PM, Jan Hubicka wrote:
>> There shouldn't be any forwarder blocks in cfg layout mode. What did
>> you need this for?
>>
>> BTW2: We badly need to figure out a way to create test cases for FDO... :-(
>
> We have gcc.dg/tree-prof and friends. What do you need to add?
> There shouldn't be any forwarder blocks in cfg layout mode. What did
> you need this for?
>
> BTW2: We badly need to figure out a way to create test cases for FDO... :-(
We have gcc.dg/tree-prof and friends. What do you need to add?
Honza
On Fri, May 10, 2013 at 5:54 PM, Teresa Johnson wrote:
> The main issue I had here, and why I made this change, is that we go
> in and out of cfglayout mode several times after bb partitioning and
> then out_of_cfglayout. The problem was that when we subsequently went
> in and out of cfglayout mode
On Thu, May 9, 2013 at 3:40 PM, Steven Bosscher wrote:
> On Thu, May 9, 2013 at 11:42 PM, Diego Novillo wrote:
>> On 2013-05-08 01:13 , Teresa Johnson wrote:
>>> -static void
>>> +void
>>> emit_barrier_after_bb (basic_block bb)
>>> {
>>>rtx barrier = emit_barrier_after (BB_END (bb));
>>> -
On Fri, May 10, 2013 at 4:52 AM, Jan Hubicka wrote:
>> On 05/07/13 23:13, Teresa Johnson wrote:
>> >--
>> >Revised patch that fixes failures encountered when enabling
>> >-freorder-blocks-and-partition, including the failure reported in PR 53743.
>> >
>> >This includes new veri
On Thu, May 9, 2013 at 2:42 PM, Diego Novillo wrote:
> On 2013-05-08 01:13 , Teresa Johnson wrote:
>>
>> Somehow Rietveld didn't upload the patch properly. I've attached the
>> patch to this email instead. Here is the description:
>
>
> Rietveld has turned out to be far less useful that I had hope
On Fri, May 10, 2013 at 12:57 AM, Xinliang David Li wrote:
> On Thu, May 9, 2013 at 3:40 PM, Steven Bosscher wrote:
>> This patch mixes up things badly from the point of
>> what-depends-on-what, the whole approach looks wrong to me.
>
>
> Do you mean the 'source file dependency' or 'logical depend
> On 05/07/13 23:13, Teresa Johnson wrote:
> >--
> >Revised patch that fixes failures encountered when enabling
> >-freorder-blocks-and-partition, including the failure reported in PR 53743.
> >
> >This includes new verification code to ensure no cold blocks dominate hot
> >bloc
On 05/07/13 23:13, Teresa Johnson wrote:
--
Revised patch that fixes failures encountered when enabling
-freorder-blocks-and-partition, including the failure reported in PR 53743.
This includes new verification code to ensure no cold blocks dominate hot
blocks contributed by
On Thu, May 9, 2013 at 3:40 PM, Steven Bosscher wrote:
> On Thu, May 9, 2013 at 11:42 PM, Diego Novillo wrote:
>> On 2013-05-08 01:13 , Teresa Johnson wrote:
>>> -static void
>>> +void
>>> emit_barrier_after_bb (basic_block bb)
>>> {
>>>rtx barrier = emit_barrier_after (BB_END (bb));
>>> -
On Thu, May 9, 2013 at 11:42 PM, Diego Novillo wrote:
> On 2013-05-08 01:13 , Teresa Johnson wrote:
>> -static void
>> +void
>> emit_barrier_after_bb (basic_block bb)
>> {
>>rtx barrier = emit_barrier_after (BB_END (bb));
>> - BB_FOOTER (bb) = unlink_insn_chain (barrier, barrier);
>> + if (
On 2013-05-08 01:13 , Teresa Johnson wrote:
Somehow Rietveld didn't upload the patch properly. I've attached the
patch to this email instead. Here is the description:
Rietveld has turned out to be far less useful that I had hoped. If you
are running ubuntu precise, the upload script is having
Thanks for the confirmation that the -g issue is orthogonal. I did
start to try to address it but got pulled away by some other things
for awhile. I'll see if I can take another stab at it.
In the meantime, could one of the global maintainers take a look at
the patch? I don't want it to get too st
Hello,
Sorry for the long delay (ref http://patchwork.ozlabs.org/patch/199397/)
On 6 December 2012 20:26, Teresa Johnson wrote:
>
>
>
> On Wed, Nov 28, 2012 at 7:48 AM, Christophe Lyon
> wrote:
>>
>> I have updated my trunk checkout, and I can confirm that eval.c now
>> compiles with your pat
On Mon, Nov 26, 2012 at 12:19:55PM -0800, Teresa Johnson wrote:
> Are you sure you have all my changes applied? I applied the 4 patches
> attached to PR55121 into my trunk checkout that has my fixes, and to a
> pristine trunk checkout. I configured and built both for
> --target=arm-none-linux-gnuea
Are you sure you have all my changes applied? I applied the 4 patches
attached to PR55121 into my trunk checkout that has my fixes, and to a
pristine trunk checkout. I configured and built both for
--target=arm-none-linux-gnueabi, and built using your options, .i file
and gcda file. I can reproduce
Hi,
I have tested your patch on Spec2000 on ARM, and I can still see
several failures caused by:
"error: fallthru edge crosses section boundary", including the case
described in PR55121.
On 26 November 2012 16:55, Teresa Johnson wrote:
> Ping.
> Teresa
>
> On Thu, Nov 15, 2012 at 12:10 PM, Teres
Ping.
Teresa
On Thu, Nov 15, 2012 at 12:10 PM, Teresa Johnson wrote:
> Revised patch that fixes failures encountered when enabling
> -freorder-blocks-and-partition, including the failure reported in PR 53743.
>
> This includes new verification code to ensure no cold blocks dominate hot
> blocks c
26 matches
Mail list logo