tejohnson added a comment.

In D36850#2990847 <https://reviews.llvm.org/D36850#2990847>, @modimo wrote:

> In D36850#2990771 <https://reviews.llvm.org/D36850#2990771>, @tejohnson wrote:
>
>> In D36850#2968536 <https://reviews.llvm.org/D36850#2968536>, @modimo wrote:
>>
>>> In D36850#2964293 <https://reviews.llvm.org/D36850#2964293>, @tejohnson 
>>> wrote:
>>>
>>>> Good point on indirect calls. Rather than add a bit to the summary, can 
>>>> the flags just be set conservatively in any function containing an 
>>>> indirect call when we build the summaries initially? I think that would 
>>>> get the same effect.
>>>
>>> That could have an issue where A calls {indirect, B} and A gets propagated 
>>> upon from B without knowledge that the indirect call exists. Right now I've 
>>> got a FunFlags `hasUnknownCall` which marks these as non-propagatable.
>>
>> Ah, because there isn't a conservative setting of the flag...which raises a 
>> larger issue (but maybe I am completely missing something) - how do we 
>> distinguish between the NoUnwind summary flag not being set because we don't 
>> know yet (in which case we want the propagation from callees), vs because it 
>> cannot be NoUnwind (because there is a throw in the function)? Do we need to 
>> have a second flag indicating that a function contains a mayThrow 
>> instruction (other than calls, which are being handled by the propagation)?
>
> Only call instructions can throw (what ultimately performs the throw 
> operation is an opaque call to __cxa_throw()) which simplifies the problem. 
> If all calls are known, we only need to examine the callees for accurate 
> propagation.

What about the other instruction checks done in Instruction::mayThrow i.e. 
http://llvm-cs.pcc.me.uk/lib/IR/Instruction.cpp#592?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D36850/new/

https://reviews.llvm.org/D36850

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to