[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 <reviews at 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
> 
> 
>