On Fri, Jul 27, 2012 at 11:40 AM, Steven Bosscher <stevenb....@gmail.com> wrote: > On Fri, Jul 27, 2012 at 11:15 AM, Richard Guenther > <richard.guent...@gmail.com> wrote: >>> Right. I don't like the use of this attribute on labels at all, for >>> the reasons you list here. I think it would be much cleaner to add a >>> branch hint on the label in the asm goto, to contain this extension >>> and to also to make it clear that it's not the label that is cold but >>> the jump that is unlikely to be executed (i.e. cause and effect: the >>> jump is unlikely and therefore the basic block is cold). >> >> As in the case where you have both an unlikely and likely jump to a >> basic-block. But what I understand is that rth adds a way to mark >> a basic-block as hot or cold, not a way to mark an edge as hot or cold >> (that would be what the asm goto annotation would do). Both cases >> are of course useful. > > I don't see why it is useful to be able to mark a basic block as hot > or cold. This is something that the compiler can figure out for itself > if you provide the branch hints (__builtin_expect is also a kind of > branch hint). Marking basic blocks as likely or unlikely seems just > redundant and confusing to me. A basic block being hot or cold is an > effect of its incoming edges being unlikely-taken, not an inherent > property of the basic block itself.
Well, I see it as a more finegrained way to force the compiler to optimize that block for size (which then leads to my question on basic-block merging and "propagating" that info). Richard. > Ciao! > Steven
