[llvm-dev] RFC: separating guards and implicit control flow

[Reid Kleckner via llvm-dev]

On Wed, May 16, 2018 at 5:53 PM Hal Finkel via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> As you likely already know, I'm not a fan of having calls that might
> unwind, or otherwise have implicit edges, in the middle of basic blocks.
> I continue to believe that they should be terminators. As such, while I
> realize that there are definite efficiency concerns about doing this in
> general (and, perhaps, a bunch of optimizations that would need to start
> looking across multiple blocks to maintain feature parity), I'm fully
> supportive of this change (I'm assuming that you've not found any
> serious compile-time implications in this regard).
>

Without being on the hook to do any of the work or hard thinking, I can say
I agree. :)

We might be able to paper over a lot of these concerns about missed
optimizations with some new ExtendedBasicBlock helpers that iterate
instructions across single-successor single-predecessor BB edges from
potentially throwing calls and trivially simplifiable unconditional
branches.

We can reuse the "unwind to caller" spelling that we already use in WinEH,
so potentially throwing calls with no landingpad would look like:
  invoke void @foo()
    to label %normal unwind to caller

We could either null out the unwind label operand of today's InvokeInst or
find a way to not avoid allocating it in the first place. That would
require a fair amount of rework, though. I'd probably just null it out for
now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180517/e156c51d/attachment.html>