[LLVMdev] RFC: How to represent SEH (__try / __except) in LLVM IR

Vadim Chugunov vadimcn at gmail.com
Wed Dec 3 14:26:11 PST 2014


On Wed, Dec 3, 2014 at 1:41 PM, Reid Kleckner <rnk at google.com> wrote:

> On Wed, Dec 3, 2014 at 1:27 PM, Vadim Chugunov <vadimcn at gmail.com> wrote:
>
>> If we added unwind target to every potentially throwing instruction
>> (loads, stores, all binary operations), wouldn't all such instructions have
>> to become BB terminators?   I'd expect that CFG would then end up
>> consisting mostly of single-instruction BBs. This can't be good for
>> compilation performance and optimizations...
>>
>
> Yes. This merely exposes the high cost of what the user is requesting. We
> could invent a more compact representation for a run of single-instruction
> bbs that share unwind edges, but *reliable* async exception support is
> fundamentally bad for optimization. Analysis passes need to see all the
> implicit edges.
>
> Another vague idea: what if lifetime.start() returned some kind of a
>> token, which lifetime.end() has to consume?   That would prevent
>> transformations that don't preserve lifetime scopes (such as the one you've
>> described), wouldn't it?
>>
>
> No, the transform is still valid. The block with the switch would contain
> a massive list of phis between undef and the incoming SSA values that were
> previously used by successor basic blocks. The incoming undef edge is not
> actually dynamically reachable, so it's safe to add undef there.
>

So what's to become of llvm.lifetime.start/end?   Are they going to be
removed or fixed?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141203/779a6dce/attachment.html>


More information about the llvm-dev mailing list