[llvm-dev] Question about GlobalOpt

[Chandler Carruth via llvm-dev]

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.

On Mon, Mar 21, 2016 at 4:02 PM Mehdi Amini <mehdi.amini at apple.com> wrote:

> On Mar 21, 2016, at 3:57 PM, Sanjin Sijaric via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hi,
>
> GlobalOpt may not consider demoting globals to locals in the “main”
> function when C is used.   It used to consider “main” specifically prior to
> commit r253168 , for both C and C++.  Since r253168, the check for the
> norecurse attribute may prevent “main” from being considered.  This happens
> because the Function Attributes pass will not add the norecurse attribute
> to functions that have calls to library functions that aren’t themselves
> marked with the norecurse attribute, such as putchar.  Even a call to
> llvm.lifetime.start, for example, will prevent a function from being
> considered as non-recursive as llvm.lifetime.start isn’t marked with the
> “norecurse” attribute.
>
> We have a C workload that benefits from this demotion with LTO, as some
> hot functions get inlined into main.
>
> The comment in tools/clang/lib/CodeGen/CodeGenFunctions.cpp explains the
> reason for marking “main” with the norecurse attribute in C++:
>
> // If we're in C++ mode and the function name is "main", it is guaranteed
> // to be norecurse by the standard (3.6.1.3 "The function main shall not be
> // used within a program").
>
> No such restriction exists in the C standard, as far as I can tell.
>
>
> This seem to be you problem.
>
>
> Is there anything that can be done to alleviate this restriction in C?
>
>
> Except if we had a source-level attribute, or a clang command line flag, I
> don't see how.
> Write your main in C++ maybe?
>
>   Can we make the Function Attributes pass more aggressive, for example?
>
>
> Are you suggesting to break C semantics or I misunderstand what you mean?
>
>
> Or mark certain library functions as “norecurse”, although I don’t see how
> this can be guaranteed.
>
>
> This is pretty recent and we don't have a good support for libcalls and
> norecurse. I think Chandler found also some conceptual issue to get it to
> work properly.
> CC: Chandler+James who probably remember more than I do now.
>
>
> --
> Mehdi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160322/ccc93651/attachment.html>