search for: d87180

...less you meant this > statement to only refer to loops in the caller that contain the > inlined call. I'm not sure I interpret "loops in the caller that contain the inlined call" correctly but let me give it a try. So this is the first inliner patch: https://reviews.llvm.org/D87180 It is alone sufficient for correctness of this scheme. A follow up can provide better optimization opportunities by using metadata to annotate loops in the caller, assuming the caller did not have the `maynotprogress` function attribute already. All loops originally in the caller would be given the...

...in the caller that contain the >>  > inlined call. >> >> I'm not sure I interpret "loops in the caller that contain the inlined >> call" correctly but let me give it a try. >> >> So this is the first inliner patch: https://reviews.llvm.org/D87180 >> It is alone sufficient for correctness of this scheme. A follow up can >> provide better optimization opportunities by using metadata to annotate >> loops in the caller, assuming the caller did not have the >> `maynotprogress` function attribute already. All loops ori...

On 9/4/20 7:39 PM, Hal Finkel via llvm-dev wrote: > > On 9/4/20 6:31 PM, Atmn Patel via llvm-dev wrote: >> Hi All, >> >> We’ve prepared a new function attribute `maynotprogress` and loop >> metadata `llvm.loop.mustprogress` in order to better formalize the way >> LLVM deals with infinite loops without observable side-effects. This >> is deeply