[LLVMdev] Exception Handling Proposal, Second round Re: LLVMdev Digest, Vol 83, Issue 30

[Peter Lawrence]

Andy,
            I think we are in complete agreement !


My admittedly superficial reading of the "Structured Exception  
Handling" patent lead me to believe that
non-connected control-flow was part of that design, and I am always  
worrying that folks are trying to leverage
off that design, so I am always trying to emphasize that that concept  
is incompatible with modern optimization
theory and practice.


-Peter.



On May 18, 2011, at 9:27 AM, Andrew Trick wrote:

> On May 18, 2011, at 8:35 AM, Peter Lawrence wrote:
>
>> Renato,
>>                I agree with what Andrew said, but would have  
>> worded it differently. All optimizers (that
>> I am aware of) require explicit control flow, so things like  
>> exception-throwing-divide-instructions
>> need to be converted into IR that are Block-Terminators.  Andrew  
>> was explaining how this is
>> a non-performance issue in practice, I am explaining how this is a  
>> requirement of how optimizer
>> are implemented in practice.
>>
>> -Peter Lawrence.
>
> Thanks for the clarification, Peter. I was trying to convey two  
> main points:
> 1) Optimizers require explicit control flow, which is not a  
> limitation because it's easy to optimize across branches (calls and  
> merges are hard to handle).
> 2) Codegen can convert control flow to trapping instructions, but  
> it's seldom worthwhile.
>
> -Andy
>
>> On May 18, 2011, at 1:34 AM, llvmdev-request at cs.uiuc.edu wrote:
>>
>>> On 18 May 2011 03:10, Andrew Trick <atrick at apple.com> wrote:
>>>> This sounds like something that came out of a brainstorming  
>>>> session then snuck into the project requirements when it's  
>>>> really a separate issue. I think you can safely ignore it.
>>>
>>> Ah, great! It was something someone asked about and I've only heard
>>> "don't worry about it" but never heard a full explanation, until  
>>> now!
>>> ;)
>>>
>>> Thanks!
>>> --renato
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110518/1d59b821/attachment.html>