[llvm-dev] Question about GlobalOpt

[Mehdi Amini via llvm-dev]

> 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>