RE: [PATCH] D28404: IRGen: Add optnone attribute on function during O0

[Robinson, Paul via cfe-commits]

(Re-add cfe-commits; otherwise same)

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of
> Duncan P. N. Exon Smith via cfe-commits
> Sent: Monday, January 09, 2017 4:10 PM
> To: reviews+d28404+public+53e0f4655ef79...@reviews.llvm.org
> Cc: nhaeh...@gmail.com; wei.di...@amd.com; jholewin...@nvidia.com; Richard
> Smith; cfe-commits; Peter Collingbourne
> Subject: Re: [PATCH] D28404: IRGen: Add optnone attribute on function
> during O0
> 
> This seems like a massive rehash of a discussion Peter Collingbourne and I
> had about passing -O0 to the linker for -flto=full.  I had previously
> thought of LTO as "link time optimization", but in practice it's useful
> for (and required for correctness of some) non-optimization IR passes.
> 
> In other words, the basic question seems to be: "Should LTO support non-
> optimization use cases?"  I tend (now) to think it should -- having
> "optimization" in its name is an historical artifact -- because adding
> another way to run IR passes at link-time seems redundant.  Whereas, Paul,
> it seems like you disagree?

I am persuaded that there are non-optimization-based uses for clumps of
bitcode modules linked together.  (We could redefine the TLA if we like;
LTO = Link Time Operation?)

I am equally convinced that we have no good story for propagating a
variety of optimization- and codegen-related options to the top-level
LTO processor.  This is most especially true when different CUs might
reasonably have different options.  -O0 is the example at hand, but 
this problem seems to keep coming up and we keep hacking in ways to get 
the thing we think we need in the moment.

> 
> (Also, this discussion seems higher level than just the patch at hand...
> maybe llvm-dev would be more appropriate?)

I'd be fine with that.
--paulr
> 
> > On 2017-Jan-09, at 16:03, Paul Robinson via Phabricator
> <revi...@reviews.llvm.org> wrote:
> >
> > probinson added a comment.
> >
> > In https://reviews.llvm.org/D28404#640588, @mehdi_amini wrote:
> >
> >> Actually, as mentioned before, I could be fine with making `O0`
> incompatible with LTO, however security features like CFI (or other sort
> of whole-program analyses/instrumentations) requires LTO.
> >
> >
> > Well, "requires LTO" is overstating the case, AFAICT from the link you
> gave me.  Doesn't depend on //optimization// at all.  It depends on some
> interprocedural analyses given some particular scope/visibility boundary,
> which it is convenient to define as a set of linked bitcode modules, that
> by some happy chance is the same set of linked bitcode modules that LTO
> will operate on.
> >
> > If it's important to support combining a bitcode version of my-
> application with your-bitcode-library for this CFI or whatever, and you
> also want to let me have my-application be unoptimized while your-bitcode-
> library gets optimized, NOW we have a use-case.  (Maybe that's what you
> had in mind earlier, but for some reason I wasn't able to extract that out
> of any prior comments.  No matter.)
> >
> > I'm now thinking along the lines of a `-foptimize-off` flag (bikesheds
> welcome) which would set the default for the pragma to 'off'.  How is that
> different than what you wanted for `-O0`?  It is defined in terms of an
> existing pragma, which is WAY easier to explain and WAY easier to
> implement.  And, it still lets us say that `-c -O0 -flto` is a mistake, if
> that seems like a useful thing to say.
> >
> > Does that seem reasonable?  Fit your understanding of the needs?
> >
> >
> > https://reviews.llvm.org/D28404
> >
> >
> >
> 
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D28404: IRGen: Add optnone attribute on function during O0

[Duncan P. N. Exon Smith via cfe-commits]

This seems like a massive rehash of a discussion Peter Collingbourne and I had 
about passing -O0 to the linker for -flto=full.  I had previously thought of 
LTO as "link time optimization", but in practice it's useful for (and required 
for correctness of some) non-optimization IR passes.

In other words, the basic question seems to be: "Should LTO support 
non-optimization use cases?"  I tend (now) to think it should -- having 
"optimization" in its name is an historical artifact -- because adding another 
way to run IR passes at link-time seems redundant.  Whereas, Paul, it seems 
like you disagree?

(Also, this discussion seems higher level than just the patch at hand... maybe 
llvm-dev would be more appropriate?)

> On 2017-Jan-09, at 16:03, Paul Robinson via Phabricator 
>  wrote:
> 
> probinson added a comment.
> 
> In https://reviews.llvm.org/D28404#640588, @mehdi_amini wrote:
> 
>> Actually, as mentioned before, I could be fine with making `O0` incompatible 
>> with LTO, however security features like CFI (or other sort of whole-program 
>> analyses/instrumentations) requires LTO.
> 
> 
> Well, "requires LTO" is overstating the case, AFAICT from the link you gave 
> me.  Doesn't depend on //optimization// at all.  It depends on some 
> interprocedural analyses given some particular scope/visibility boundary, 
> which it is convenient to define as a set of linked bitcode modules, that by 
> some happy chance is the same set of linked bitcode modules that LTO will 
> operate on.
> 
> If it's important to support combining a bitcode version of my-application 
> with your-bitcode-library for this CFI or whatever, and you also want to let 
> me have my-application be unoptimized while your-bitcode-library gets 
> optimized, NOW we have a use-case.  (Maybe that's what you had in mind 
> earlier, but for some reason I wasn't able to extract that out of any prior 
> comments.  No matter.)
> 
> I'm now thinking along the lines of a `-foptimize-off` flag (bikesheds 
> welcome) which would set the default for the pragma to 'off'.  How is that 
> different than what you wanted for `-O0`?  It is defined in terms of an 
> existing pragma, which is WAY easier to explain and WAY easier to implement.  
> And, it still lets us say that `-c -O0 -flto` is a mistake, if that seems 
> like a useful thing to say.
> 
> Does that seem reasonable?  Fit your understanding of the needs?
> 
> 
> https://reviews.llvm.org/D28404
> 
> 
> 

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits