[llvm-dev] Question about GlobalOpt

[James Molloy via llvm-dev]

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>