llvm dev - Mar 2016 - Question about GlobalOpt

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.

 

Is there anything that can be done to alleviate this restriction in C?  Can
we make the Function Attributes pass more aggressive, for example?  Or mark
certain library functions as "norecurse", although I don't see how
this can
be guaranteed.

 

Thanks,

Sanjin

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160321/68c69055/attachment.html>

> 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/20160321/48d4e9a5/attachment-0001.html>

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>

Hi Mehdi,

 

You are right – modifying the Function Attributes pass to mark “main” as
norecurse would break the C standard (unless it has a similar statement
regarding “main” that the C++ standard has – I cannot find it), so that’s a
no-go.  Looks like there was an attempt to bypass library calls in the Function
Attributes pass for the purpose of detecting norecurse functions:
http://reviews.llvm.org/D14769.  I’ll look for other threads on this topic.

 

Thanks,

Sanjin

 

From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] 
Sent: Monday, March 21, 2016 4:02 PM
To: Sanjin Sijaric <ssijaric at codeaurora.org>
Cc: LLVM Dev Mailing List <llvm-dev at lists.llvm.org>; Chandler Carruth
<chandlerc at google.com>; James Molloy <james at jamesmolloy.co.uk>
Subject: Re: [llvm-dev] Question about GlobalOpt

 

            

On Mar 21, 2016, at 3:57 PM, Sanjin Sijaric via llvm-dev <llvm-dev at
lists.llvm.org <mailto: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/1f32aa3c/attachment.html>