>> 1) fixes the problem, so 5 and 4 are now in the same partition. The fix
>> is quite trivial, as with attached.
>
> That looks obviously correct to me. I can't approve it, but I'd have
> committed it as obvious.
>
Thanks, I'll make the formal request, after checking forthe unexpected
side e
On Wed, Sep 12, 2012 at 4:47 AM, Christian Bruel wrote:
> The problem stems from tree-ssa-tail-merge that breaks bb->count, The
> CFG looks like
>
> 2
>/ \
> /6
> 5 (0) |
> | 3 <-
> |/ \ |
> | 7 (1) 8 -
> | /
> 4 (1)
>
> (in parenthesis the bb->count from
The problem stems from tree-ssa-tail-merge that breaks bb->count, The
CFG looks like
2
/ \
/6
5 (0) |
| 3 <-
|/ \ |
| 7 (1) 8 -
| /
4 (1)
(in parenthesis the bb->count from gcov)
2
/ \
/6
/ |
| 3 <--
| / | |
5 (0) 8 --
On Tue, Sep 11, 2012 at 05:40:30PM +0200, Steven Bosscher wrote:
> On Tue, Sep 11, 2012 at 5:31 PM, Christian Bruel
> wrote:
> > Actually, the edge is fairly simple. I have
> >
> > BB5 (BB_COLD_PARTITION) -> BB10 (BB_HOT_PARTITION) -> EXIT
> >
> > and BB10 has no other incoming edges. and we are
when running a cfg dump, I get many messages like:
Invalid sum of incoming frequencies 1667, should be 3334
So it looks like a profile information was not correctly propagated
somewhere. which could lead to such partitioning incoherency. I have no
idea for the moment if this is local problem or n
On 09/11/2012 05:40 PM, Steven Bosscher wrote:
> On Tue, Sep 11, 2012 at 5:31 PM, Christian Bruel
> wrote:
>> Actually, the edge is fairly simple. I have
>>
>> BB5 (BB_COLD_PARTITION) -> BB10 (BB_HOT_PARTITION) -> EXIT
>>
>> and BB10 has no other incoming edges. and we are duplicating it.
>
>
On Tue, Sep 11, 2012 at 5:31 PM, Christian Bruel wrote:
> Actually, the edge is fairly simple. I have
>
> BB5 (BB_COLD_PARTITION) -> BB10 (BB_HOT_PARTITION) -> EXIT
>
> and BB10 has no other incoming edges. and we are duplicating it.
That is wrong, should never happen. Is there a test case to pla
Actually, the edge is fairly simple. I have
BB5 (BB_COLD_PARTITION) -> BB10 (BB_HOT_PARTITION) -> EXIT
and BB10 has no other incoming edges. and we are duplicating it.
My hypothesis, is that with a gcov based profile, we should never have
such partitioning on the edges, BB10 should be COLD as we
> Does this restriction look right to you ? (regression tests are still
> running on x86 and sh)
Please generate your patches with diff -up (or svn diff -x -up).
> + && (BB_PARTITION (e->src) == BB_PARTITION (e->dest))
No need for parentheses around this check.
The shrink wrapping c
Hello,
While testing the patch to enable shrink-wrapping on SH [PR54546], we
hit an the "error: EDGE_CROSSING missing across section boundary"
Indeed, shrink-wrap duplicates a bb with successors (containing the
return sequence) into an unlikely section. I first thought about setting
the EDGE_CROS
10 matches
Mail list logo
