llvm dev - May 2011 - [LLVMdev] Exception Handling Proposal, Second round Re: LLVMdev Digest, Vol 83, Issue 30

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.


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110518/e91bb1c6/attachment.html>

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/17c809bc/attachment.html>

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>