Displaying 3 results from an estimated 3 matches for "mayunwind".
2017 Jan 05
3
RFC: Allow readnone and readonly functions to throw exceptions
On 01/05/2017 03:10 PM, Reid Kleckner wrote:
> On Thu, Jan 5, 2017 at 10:39 AM, Hal Finkel <hfinkel at anl.gov
> <mailto:hfinkel at anl.gov>> wrote:
>
> I don't understand why that's desirable, and I think it would
> severely limit our ability to infer these attributes for functions
> that unwind. You'd need to prove things -- likely
2017 Jan 05
2
RFC: Allow readnone and readonly functions to throw exceptions
...t unwinds, than
>> the later store is dead. If I know that &*a has not escaped to where an
>> exception handler might access it, then I know that the first store than be
>> removed.
> That's not specific to readnone though, right? Even if the function
> was readonly-mayunwind, the optimization would be legal.
Yes, unless the readonly-mayunwind functions takes the memory as a
parameter, in which case the latter sentence does not apply.
-Hal
>
>> -Hal
>>
>>
>>
>> I don't think we'll do DSE in your example because the store i...
2017 Jan 05
2
RFC: Allow readnone and readonly functions to throw exceptions
...oss readnone maythrow function
>>> calls because the
>>> exception handler could read memory. That is, in:
>>>
>>> try {
>>> *a = 10;
>>> call void @readnone_mayunwind_fn();
>>> *a = 20;
>>> } catch (...) {
>>> assert(*a == 10);
>>> }
>>>
>>> I can't DSE the `*a = 10` store.
>>>
>>> As...