[llvm-dev] [RFC] Adding function attributes to represent codegen optimization level

[Chad Rosier via llvm-dev]

Hi Martin,

I think this is another example of why we might consider having such 
function level attributes.. yes.

  Chad


On 4/4/2018 11:42 AM, Martin J. O'Riordan via llvm-dev wrote:
>
> Sorry, my reply “to all” left out LLVM-Dev
>
> *From:*Martin J. O'Riordan [mailto:MartinO at theheart.ie]
> *Sent:* 04 April 2018 16:41
> *To:* 'David Blaikie' <dblaikie at gmail.com>; 'mcrosier at codeaurora.org' 
> <mcrosier at codeaurora.org>; 'Chandler Carruth' <chandlerc at gmail.com>; 
> 'Eric Christopher' <echristo at gmail.com>
> *Subject:* RE: [llvm-dev] [RFC] Adding function attributes to 
> represent codegen optimization level
>
> Would implementing GCC’s ‘__attribute__((optimize(...)))’ help?
>
> I can’t find any good documentation for this attribute, but it seems 
> that GCC supports this in two forms:
>
> __attribute__((optimize(2)))
>
> meaning optimise equivalent to ‘-O2’, and:
>
> __attribute_((optimize("fblah", "O1")))
>
> meaning optimise with the provided discrete options.
>
> MartinO
>
> *From:*llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of 
> *David Blaikie via llvm-dev
> *Sent:* 04 April 2018 15:41
> *To:* mcrosier at codeaurora.org <mailto:mcrosier at codeaurora.org>; 
> Chandler Carruth <chandlerc at gmail.com <mailto:chandlerc at gmail.com>>; 
> Eric Christopher <echristo at gmail.com <mailto:echristo at gmail.com>>
> *Cc:* llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> *Subject:* Re: [llvm-dev] [RFC] Adding function attributes to 
> represent codegen optimization level
>
> On Tue, Apr 3, 2018 at 12:47 PM via llvm-dev <llvm-dev at lists.llvm.org 
> <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>     All,
>     A recent commit, D43040/r324557, changed the behavior of the gold
>     plugin
>     when compiling with LTO.  The change now causes the codegen
>     optimization
>     level to default to CodeGenOpt::Default (i.e., -O2) rather than
>     use the
>     LTO optimization level.  The argument was made that the LTO
>     optimization
>     level should control the amount of cross-module optimizations done by
>     LTO, but it should not control the codegen optimization level; that
>     should be based off of the optimization level used during the initial
>     compilation phase (i.e., bitcode generation).
>
>
> At least as I recall the discussion around optnone/optsize in the pass 
> was that these were in some way special semantically distinct 
> properties (optnone being "good for debugging" (or good for debugging 
> compilers - what's the baseline behavior before optimizations are 
> applied), optsize being "make this fit into something it wouldn't 
> otherwise fit into") but that the gradiations of -ON didn't fit into 
> this kind of model & wouldn't ever be implemented as function attributes.
>
> CC'd Chandler & Eric who I think had opinions/were involved in those 
> previous discussions.
>
>
>     Assuming the argument is reasonable (it make sense to me), I was
>     hoping
>     to solicit feedback on how to proceed.  The suggestion in
>     D43040/r324557
>     was to add function attributes to represent the compile-time
>     optimization level (which also seems reasonable to me).
>
>     As a first step, I've put together two patches: 1) an llvm patch that
>     adds the function attributes to the LLVM IR and 2) a clang patch that
>     attaches these attributes to each function based on the codegen
>     optimization level.  I then use the function level attributes to
>     "reconstruct" to codegen optimization level used with LTO.
>
>     Please understand this is very much a WIP and just a very small step
>     towards a final solution.
>
>     Here are the patches for reference:
>     Clang: D45226
>     LLVM: D45225
>
>     Regards,
>       Chad
>
>
>     _______________________________________________
>     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
>
>
>
> _______________________________________________
> 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/20180404/6a2e9f87/attachment.html>