Hi, On my phone right now but I'll fish out the pertinent threads when I get to the office. Keyword searches for 'norecurse' on llvm-dev will probably get most of them. Indeed, this correctness improvement caused a performance regression on some programs. There is a way to revert to the old, broken behaviour: '-mllvm -force-attribute=main:norecurse'. Given how many people run old C code that rely on this property I wouldn't be against adding an appropriate frontend option for this either, but I am not a clang Dev so they might object more :) Many library functions can be implemented in a recursive fashion. The issue is the same as we've had elsewhere in LLVM- is there a defined visibility boundary between user and library code? The same problem can be seen in the Malloc attribute annotations (I forget the attribute name) that Vaiva created - having one arbitrary visibility barrier breaks down when libraries are LTOd (bare metal or OpenCl systems being examples) Norecurse as a concept is a trade off between ease of inference and ease of definition. Norecurse is indeed hard for the compiler to infer, but the definition is precise. There may be other, superior options - suggestions welcome! :) Cheers, James On Tue, 22 Mar 2016 at 01:15, Sanjoy Das via llvm-dev < llvm-dev at lists.llvm.org> wrote:> On Mon, Mar 21, 2016 at 5:34 PM, Chandler Carruth via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > I think the conceptual issues have largely been sorted out, it is mostly > > that it is *much* harder to deduce norecurse than it might seem like > > superficially. > > Is there a specific thread / email I can look at to read about what > the issues were? > > -- Sanjoy > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160322/20700a5f/attachment.html>
> On Mar 22, 2016, at 12:09 AM, James Molloy via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > On my phone right now but I'll fish out the pertinent threads when I get to the office. Keyword searches for 'norecurse' on llvm-dev will probably get most of them. > > Indeed, this correctness improvement caused a performance regression on some programs. There is a way to revert to the old, broken behaviour: '-mllvm -force-attribute=main:norecurse'. Given how many people run old C code that rely on this property I wouldn't be against adding an appropriate frontend option for this either, but I am not a clang Dev so they might object more :) > > Many library functions can be implemented in a recursive fashion. The issue is the same as we've had elsewhere in LLVM- is there a defined visibility boundary between user and library code? The same problem can be seen in the Malloc attribute annotations (I forget the attribute name) that Vaiva created - having one arbitrary visibility barrier breaks down when libraries are LTOd (bare metal or OpenCl systems being examples)By adding the attributes only on libcalls *declarations* only, you solve most of the issues: if you're in the translation unit that exposes the internal implementation of malloc you won't have the attribute (we could imagine that one would implement "strlen" split in multiple files, but that's quite unlikely). -- Mehdi> > Norecurse as a concept is a trade off between ease of inference and ease of definition. Norecurse is indeed hard for the compiler to infer, but the definition is precise. > > There may be other, superior options - suggestions welcome! :) > > Cheers, > > James > On Tue, 22 Mar 2016 at 01:15, Sanjoy Das via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > On Mon, Mar 21, 2016 at 5:34 PM, Chandler Carruth via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > I think the conceptual issues have largely been sorted out, it is mostly > > that it is *much* harder to deduce norecurse than it might seem like > > superficially. > > Is there a specific thread / email I can look at to read about what > the issues were? > > -- Sanjoy > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160322/76db5317/attachment.html>
That could work! But the bigger problem (that I've just remembered) is hooks and callbacks. If a function can either exit, abort or Malloc it could call back into user code. That said, those functions (strtok etc) are a smaller subset of the library. James On Tue, 22 Mar 2016 at 07:21, Mehdi Amini <mehdi.amini at apple.com> wrote:> On Mar 22, 2016, at 12:09 AM, James Molloy via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Hi, > > On my phone right now but I'll fish out the pertinent threads when I get > to the office. Keyword searches for 'norecurse' on llvm-dev will probably > get most of them. > > Indeed, this correctness improvement caused a performance regression on > some programs. There is a way to revert to the old, broken behaviour: > '-mllvm -force-attribute=main:norecurse'. Given how many people run old C > code that rely on this property I wouldn't be against adding an appropriate > frontend option for this either, but I am not a clang Dev so they might > object more :) > > Many library functions can be implemented in a recursive fashion. The > issue is the same as we've had elsewhere in LLVM- is there a defined > visibility boundary between user and library code? The same problem can be > seen in the Malloc attribute annotations (I forget the attribute name) that > Vaiva created - having one arbitrary visibility barrier breaks down when > libraries are LTOd (bare metal or OpenCl systems being examples) > > > > By adding the attributes only on libcalls *declarations* only, you solve > most of the issues: if you're in the translation unit that exposes the > internal implementation of malloc you won't have the attribute (we could > imagine that one would implement "strlen" split in multiple files, but > that's quite unlikely). > > -- > Mehdi > > > > > Norecurse as a concept is a trade off between ease of inference and ease > of definition. Norecurse is indeed hard for the compiler to infer, but the > definition is precise. > > There may be other, superior options - suggestions welcome! :) > > Cheers, > > James > On Tue, 22 Mar 2016 at 01:15, Sanjoy Das via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On Mon, Mar 21, 2016 at 5:34 PM, Chandler Carruth via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> > I think the conceptual issues have largely been sorted out, it is mostly >> > that it is *much* harder to deduce norecurse than it might seem like >> > superficially. >> >> Is there a specific thread / email I can look at to read about what >> the issues were? >> >> -- Sanjoy >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160322/abf75b89/attachment.html>