>
> >>>I hope so too. For the kernel we have some parts where
> >>>__builtin_expect is used quite a lot and noticably helps, and could
> >>>help even more if we cut down the use of cmov too. I guess on
> >>>architectures with even more predictated instructions it could be
> >>>even more useful too
I hope so too. For the kernel we have some parts where
__builtin_expect is used quite a lot and noticably helps, and could
help even more if we cut down the use of cmov too. I guess on
architectures with even more predictated instructions it could be
even more useful too.
Looking at kernel's __
On Tuesday 04 March 2008 00:01, Jan Hubicka wrote:
> > On Monday 03 March 2008 22:38, Jan Hubicka wrote:
> > I hope so too. For the kernel we have some parts where
> > __builtin_expect is used quite a lot and noticably helps, and could
> > help even more if we cut down the use of cmov too. I guess
> On Monday 03 March 2008 22:38, Jan Hubicka wrote:
> > Hi,
> > I had to tweak the testcase a bit to not compute minimum: GCC optimizes
> > this early into MIN_EXPR throwing away any profile information. If we
> > get serious here we can maintain it via histogram, but I am not sure it
> > is worth
On Monday 03 March 2008 22:38, Jan Hubicka wrote:
> Hi,
> I had to tweak the testcase a bit to not compute minimum: GCC optimizes
> this early into MIN_EXPR throwing away any profile information. If we
> get serious here we can maintain it via histogram, but I am not sure it
> is worth the effort
> > But I can also hide the cfun->function_frequency trick in
> > DEFAULT_BRANCH_COST macro if it seems to help. (in longer term I hope
> > they will all go away as expansion needs to be aware of hotness info
> > anyway)
>
> Well, it definitly helps. I originally hoped there will be fewer places
> But I can also hide the cfun->function_frequency trick in
> DEFAULT_BRANCH_COST macro if it seems to help. (in longer term I hope
> they will all go away as expansion needs to be aware of hotness info
> anyway)
Well, it definitly helps. I originally hoped there will be fewer places
querying BRA
>
> >/* High branch cost, expand as the bitwise OR of the conditions.
> > Do the same if the RHS has side effects, because we're effectively
> > turning a TRUTH_OR_EXPR into a TRUTH_ORIF_EXPR. */
> >! if (BRANCH_COST (!optimize_size, false)>= 4
> >! || TREE_SIDE_EFFEC
/* High branch cost, expand as the bitwise OR of the conditions.
Do the same if the RHS has side effects, because we're effectively
turning a TRUTH_OR_EXPR into a TRUTH_ORIF_EXPR. */
! if (BRANCH_COST (!optimize_size, false)>= 4
! || TREE_SIDE_EFFECTS (TR
Hi,
I had to tweak the testcase a bit to not compute minimum: GCC optimizes
this early into MIN_EXPR throwing away any profile information. If we
get serious here we can maintain it via histogram, but I am not sure it
is worth the effort at least until IL is sanitized and expansion cleaned
up with
10 matches
Mail list logo
