[llvm-dev] RFC: Add guard intrinsics to LLVM
Sanjoy Das via llvm-dev
llvm-dev at lists.llvm.org
Tue Feb 23 08:51:21 PST 2016
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
> 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
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
> - 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.
> I don’t think those are really fundamental
> problems though aside from adding a large number of return block
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.
More information about the llvm-dev