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

[Sanjoy Das via llvm-dev]

On Mon, Feb 22, 2016 at 11:05 PM, Andrew Trick <atrick at apple.com> wrote:
>
> I didn’t know intrinsics could be polymorphic on the return type.

@llvm.experimental.gc.result is polymorphic on its return type, for
instance.

> I understand why you’re doing this: explicitly model the
> resume-at-return path. But…
>
> - It’s a bit awkward vs. side_exit(); unreachable, as evidenced by
> inlining.

Part of the reason why we thought this scheme,
return-result-of-side-exit, was better than the
side-exit-then-unreachable scheme is that the former is more honest
about data flow; and that would prevent some nastiness around IPA. But
given that we're talking about introducing an `interposable` attribute
that prevents IPA, the side-exit-then-unreachable approach sounds
feasible now.  I need to see if there are other reasons for keeping
the return-result-of-side-exit variant; if not, I'll use the
side-exit-then-unreachable scheme.

> - It would be nice to be able to model frequent OSR points as
> branch-to-unreachable because it may lead to better optimization,
> codegen, and compile time.

Agreed.

> I don’t think those are really fundamental
> problems though aside from adding a large number of return block
> users

Return block users?  Does LLVM coalesce all `ret` instructions to a
single `ret PHI`?  I couldn't reproduce this in a small example IR.

> but it may be work to find all of the small performance issues.
>
> - Do you think this will make sense for all return argument
> conventions, including sret?

I'm not very familiar with sret, but skimming the docs I don't see why
not.  But generally, the frontend will have to know to generate
@side_exits that are legal.

-- Sanjoy