On May 9, 2012, at 2:29 AM, Richard Osborne wrote:
> On 07/05/12 22:58, Dan Gohman wrote:
>> What kind of things might basic block metadata be used for?
>>
>> Dan
> I'd be really keen for this to go in. In order to support worse case
execution time analysis on compiled binaries we (XMOS) need a way to mark paths
that should be excluded when checking timing constraints. A typical query is
"Check the worse case execution time from A to B excluding paths which pass
through location C is no more than x nanoseconds". Here C would be a
location marked in the source code. A natural way to implement this would be to
have the frontend attach metadata to the basic block containing C associating
the block with the label "C". Trying to attach the information to an
individual instruction is problematic since that specific instruction might be
removed / hoisted. Other solutions I can think of might prevent optimizations
from happening (which is something we want to avoid).
Attaching metadata to a block isn't completely free of problems either,
because blocks
can be merged, duplicated, and so on.
A possible alternative approach would be to use a special inline asm, like
asm volatile ("# my special anchor");
(written here as C syntax because it's easier in email)
as an anchor to mark a position in the program. Today, LLVM treats this as
reading
and writing arbitrary memory, which blocks memory optimizations, but this seems
to be over-conservative, since GCC does not (GCC requires the explicit
"memory"
clobber to indicate memory use). If this were fixed, such an inline asm would be
a
convenient way to mark a position in a program in a way that wouldn't be
lightly
deleted or moved, and it would have a minimal impact on optimization.
As long as LLVM's target-independent optimizers don't start interpreting
inline asm
strings, which seems a sane assumption.
Dan