[llvm-dev] RFC: Add guard intrinsics to LLVM

[Sanjoy Das via llvm-dev]

Hi Andy,

Responses inline:

On Mon, Feb 22, 2016 at 10:08 AM, Andrew Trick <atrick at apple.com> wrote:
>> By memory barrier, do you mean things like fences?
> That’s right. Conservatively, I would not hoist at the LLVM level past
> opaque non-readonly calls or fences.

Just for curiosity:  why do you care about memory fences specifically?

> I've begun to think that may-unwind (or may fail guard) and readonly
> should be mutually exclusive. readonly refers to all system memory,
> not just LLVM-visible memory. To achieve the effect of
> "aliases-with-nothing-in-llvm" it's cleaner to use alias analysis.

(I've put this on the bug as well:)

https://llvm.org/bugs/show_bug.cgi?id=18912#c3

```
(In reply to comment #2)
> The test case in this bug report is fixed by
> http://reviews.llvm.org/rL256728.
>
> I'm closing this because I don't have a test case and I no longer think it
> makes much sense to mark may-unwind calls "readonly". An unwind path always
> touches some memory. That fact that it doesn't alias with LLVM-visible

I'm not sure about this -- why does an unwind path *have* to write
some memory? Can't you implement unwind as "read the appropriate
exception handler RPC from a table, and return to that RPC"?
```

> memory access can be handled by alias analysis.

Btw, I think in this interpretation it is incorrect for -functionattrs
to infer readnone for @foo in (which it does today):

define void @foo({ i8*, i32 } %val) personality i8 8 {
  resume { i8*, i32 } %val
}

> I meant readonly can always be a property of the call site as opposed an intrinsic
> property for more frontend control

Yes, I agree that if we decide that readonly semantics are fine, we
can always explicitly mark these as readonly, and not have to worry
about specifying the memory effects as part of the intrinsics
definition.  Part of the discussion here has devolved to is "readonly"
is correct.

> I was thinking that that "unwind" would be repurposed as you say. But
> after responding to your points below, I think that could be
> misleading. It's probably cleaner to adhere to the rule that unwinding
> can only resume in a landing pad.

Ok.

> I understand your problem. I was ignoring an aspect of analyzing the
> unwind path and the fact the LLVM could make assumptions about where
> control will resume.
>
> mayBeOverriden makes sense. I would think that the symbol at the deopt
> call site needs to be marked mayBeOverriden.

Ok.  I'll probably split off an "introduce a `interposable` function
attribute" into an independent review (I think re-using a linkage type
for this will be somewhat of a hack).

Thanks!
-- Sanjoy