search for: d38336

...ong-standing LLVM bug: https://bugs.llvm.org/show_bug.cgi?id=965 I wrote a patch implementing Chandler's idea from the above thread, @llvm.sideeffect, a new intrinsic which is a no-op except that it tells the optimizer to behave as if there were side effects present: https://reviews.llvm.org/D38336 Similar results can be achieved with empty inline asms, however they tend to pessimize optimizations. The patch above allows all of the major optimizations to work in the presence of @llvm.sideeffect. One of the concerns raised is that front-ends would have to emit a lot of these intrinsics, pote...

...gt; behavior (and in particular in C++). > > I was wondering how it would be viewed the possibility of adding a flag to > loop deletion that allows the removal of loops with loop counts that are not > SCEVable. > You probably have seen it, but, for reference https://reviews.llvm.org/D38336 (which goes in the exact opposite direction). I don't necessarily fancy the idea of having a flag, instead, maybe, the frontend could emit enough information to tell the optimizer whether it is safe to remove the loop? Thanks, -- Davide

...s://bugs.llvm.org/show_bug.cgi?id=965 > > I wrote a patch implementing Chandler's idea from the above thread, > @llvm.sideeffect, a new intrinsic which is a no-op except that it tells the > optimizer to behave as if there were side effects present: > > https://reviews.llvm.org/D38336 > > Similar results can be achieved with empty inline asms, however they tend > to pessimize optimizations. The patch above allows all of the major > optimizations to work in the presence of @llvm.sideeffect. > > > I think that we should move forward with this approach (as may...

Hello! I read a bunch of discussions about the matter on this very mailing-list that are relatively recent or relatively old and I couldn’t find much agreement on the matter, so … here again :D LoopDeletion and infinite loops … Currently LoopDeletion bails if non-detectable trip count loops are encountered and that’s fine, there are languages where infinite loops without side effects cannot be

...+). >> >> I was wondering how it would be viewed the possibility of adding a flag to >> loop deletion that allows the removal of loops with loop counts that are not >> SCEVable. >> > > You probably have seen it, but, for reference > https://reviews.llvm.org/D38336 (which goes in the exact opposite direction). > > I don't necessarily fancy the idea of having a flag, instead, maybe, > the frontend could emit enough information to tell the optimizer > whether it is safe to remove the loop? > > Thanks, > > -- > Davide

...;>> I was wondering how it would be viewed the possibility of adding a flag to >>> loop deletion that allows the removal of loops with loop counts that are not >>> SCEVable. >>> >> You probably have seen it, but, for reference >> https://reviews.llvm.org/D38336 (which goes in the exact opposite direction). >> >> I don't necessarily fancy the idea of having a flag, instead, maybe, >> the frontend could emit enough information to tell the optimizer >> whether it is safe to remove the loop? >> >> Thanks, >> >&...

...ll under discussion, and we’re definitely open to changing them.) Atmn and Johannes [1] https://bugs.llvm.org/show_bug.cgi?id=965 [2] https://lists.llvm.org/pipermail/llvm-dev/2015-July/088103.html [3] https://lists.llvm.org/pipermail/llvm-dev/2017-October/118558.html [4] https://reviews.llvm.org/D38336 [5] https://reviews.llvm.org/D65718 [6] https://eel.is/c++draft/intro.progress

...> >>  >> [1] https://bugs.llvm.org/show_bug.cgi?id=965 >>  >> [2] https://lists.llvm.org/pipermail/llvm-dev/2015-July/088103.html >>  >> [3] https://lists.llvm.org/pipermail/llvm-dev/2017-October/118558.html >>  >> [4] https://reviews.llvm.org/D38336 >>  >> [5] https://reviews.llvm.org/D65718 >>  >> [6] https://eel.is/c++draft/intro.progress > > >

...gt;> >> Atmn and Johannes >> >> [1] https://bugs.llvm.org/show_bug.cgi?id=965 >> [2] https://lists.llvm.org/pipermail/llvm-dev/2015-July/088103.html >> [3] https://lists.llvm.org/pipermail/llvm-dev/2017-October/118558.html >> [4] https://reviews.llvm.org/D38336 >> [5] https://reviews.llvm.org/D65718 >> [6] https://eel.is/c++draft/intro.progress >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev...

...s.llvm.org/show_bug.cgi?id=965 >>  >>  >> [2] https://lists.llvm.org/pipermail/llvm-dev/2015-July/088103.html >>  >>  >> [3] >> https://lists.llvm.org/pipermail/llvm-dev/2017-October/118558.html >>  >>  >> [4] https://reviews.llvm.org/D38336 >>  >>  >> [5] https://reviews.llvm.org/D65718 >>  >>  >> [6] https://eel.is/c++draft/intro.progress >>  > >>  > >>  > >> > >

...t; >> >> [2] >> https://lists.llvm.org/pipermail/llvm-dev/2015-July/088103.html >> >> >> >> [3] >> >> https://lists.llvm.org/pipermail/llvm-dev/2017-October/118558.html >> >> >> >> [4] https://reviews.llvm.org/D38336 >> >> >> >> [5] https://reviews.llvm.org/D65718 >> >> >> >> [6] https://eel.is/c++draft/intro.progress >> >> > >> >> > >> >> > >> >> >> > >> > >> &...

...;> >> >> [1] https://bugs.llvm.org/show_bug.cgi?id=965 >> >> [2] https://lists.llvm.org/pipermail/llvm-dev/2015-July/088103.html >> >> [3] https://lists.llvm.org/pipermail/llvm-dev/2017-October/118558.html >> >> [4] https://reviews.llvm.org/D38336 >> >> [5] https://reviews.llvm.org/D65718 >> >> [6] https://eel.is/c++draft/intro.progress >> >> _______________________________________________ >> >> LLVM Developers mailing list >> >> llvm-dev at lists.llvm.org >> >&...