This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] asm goto


Richard Henderson <rth@redhat.com> writes:
> +@smallexample
> +#define TRACE1(NUM)                         \
> +  do {                                      \
> +    asm goto ("0: nop;"                     \
> +              ".pushsection trace_table;"   \
> +              ".long 0b, %l0;"              \
> +              ".popsection"                 \
> +	      : : : : trace#NUM);           \
> +    if (0) { trace#NUM: trace(); }          \
> +  } while (0)
> +#define TRACE  TRACE1(__COUNTER__)
> +@end smallexample
> +
> +In this example (which in fact inspired the @code{asm goto} feature)
> +we want on rare occasions to call the @code{trace} function; on other
> +occasions we'd like to keep the overhead to the absolute minimum.
> +The normal code path consists of a single @code{nop} instruction.
> +However, we record the address of this @code{nop} together with the
> +address of a label that calls the @code{trace} function.  This allows
> +the @code{nop} instruction to be patched at runtime to be an 
> +unconditional branch to the stored label.  It is assumed that an
> +optimizing compiler will move the labeled block out of line, to
> +optimize the fall through path from the @code{asm}.

Isn't the prediction logic a little too subtle here?  I.e. the fact that
in

// bb0
if (foo)
  goto L1;

if (0)
{
  L1:
  // bb1
}

// bb2
L2:

We assume that bb0->bb2 is more likely than bb0->bb1?  Is this BTW a
heuristic we already have?  PRED_GOTO maybe?

Adam


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]