[llvm-dev] Question about GlobalOpt

James Molloy via llvm-dev llvm-dev at lists.llvm.org
Tue Mar 22 00:09:30 PDT 2016


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>


More information about the llvm-dev mailing list