[LLVMdev] Proposal for safe-to-execute meta-data for heap accesses

[Chandler Carruth]

On Fri, Nov 8, 2013 at 8:44 AM, Filip Pizlo <fpizlo at apple.com> wrote:

> Is the expectation that to utilize this metadata an optimization pass
> would have to inspect the body of @f and reason about its behavior given
> <args>?
>
>
> Yes.
>
>
> If so, then I think this is pretty bad. If we ever want to parallelize
> function passes, then they can't inspect the innards of other functions.
>
>
> I must be missing something. Can't you do some simple locking?  Lock a
> function if it's being transformed, or if you want to inspect it...
>

I really, *really* don't like this.

I do *not* want parallelizing LLVM to require careful locking protocols to
be followed. Instead, I want the design to naturally arrange for different
threads to operate on different constructs and for the interconnecting
interfaces to be thread safe. The best system we have yet devised for this
is based around function passes not digging into tho bodies of other
functions. Instead we rely on attributes to propagate information about the
body of another function to a caller.


>
> So this would significantly constrain the utility here.
>
>
> I think we can engineer around this problem. For example, the function @f
> is meant to contain basically hand-written IR; it ought not be necessary to
> optimize it in order to make use of it for safe-to-execute. It's also
> reasonable to expect these to be small.
>
> Hence you can imagine freezing a copy of those functions that are used in
> this meta-data.
>

At this point, you are essentially proposing that these functions are a
similar but not quite the same IR... They will have the same concepts but
subtly different constraints or "expectations".

I'm not yet sure how I feel about this. It could work really well, or it
could end up looking a lot like ConstantExpr and being a pain for us going
forward. I'm going to keep thinking about this though and see if I can
contribute a more positive comment. =]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131108/e0d6089e/attachment.html>