llvm dev - Dec 2014 - [LLVMdev] RFC: How to represent SEH (__try / __except) in LLVM IR

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>

On Wed, Dec 3, 2014 at 2:26 PM, Vadim Chugunov <vadimcn at gmail.com>
wrote:
>
> So what's to become of llvm.lifetime.start/end?   Are they going to be
> removed or fixed?
>
Arnaud is looking at them. They are only an optimization hint, though, so
it's OK if analysis fails a variable is considered live across the entire
function. It's not OK if we think that a landing pad is active over the
entire function.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141203/63fa6dc9/attachment.html>

From: Reid Kleckner [mailto:rnk at google.com] 
Sent: 04 December 2014 00:17
To: Vadim Chugunov; Arnaud De Grandmaison
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] RFC: How to represent SEH (__try / __except) in LLVM IR

 

On Wed, Dec 3, 2014 at 2:26 PM, Vadim Chugunov <vadimcn at gmail.com>
wrote:

So what's to become of llvm.lifetime.start/end?   Are they going to be
removed or fixed?

 

Arnaud is looking at them. They are only an optimization hint, though, so
it's OK if analysis fails a variable is considered live across the entire
function. It's not OK if we think that a landing pad is active over the
entire function.

 

As far as I know, there is no plan to remove the lifetime.start/end or change
their specification. I am working on improving how they are used in clang’s IR
codegen --- which proves to be tricky. With a wider usage of them, there will
probably have to be some corner cases to be fixed here and there in llvm’s
passes.

Cheers,

Arnaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141204/b1b51c40/attachment.html>