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

[Paul Robinson via Phabricator via cfe-commits]

probinson added a comment.

In https://reviews.llvm.org/D28404#640178, @mehdi_amini wrote:

> In https://reviews.llvm.org/D28404#640170, @probinson wrote:
>
> > In https://reviews.llvm.org/D28404#640090, @mehdi_amini wrote:
> >
> > > In https://reviews.llvm.org/D28404#640046, @probinson wrote:
> > >
> > > > "I don't care" doesn't seem like much of a principle.
> > >
> > >
> > > Long version is: "There is no use-case, no users, so I don't have much motivation to push it forward for the only sake of completeness". Does it sound enough of a principle like that?
> >
> >
> > No.  You still need to have adequate justification for your use case, which I think you do not.
>
>
> I don't follow your logic. 
>  IIUC, you asked about "why not supporting `O1/O2/O3`" ; how is *not supporting* these because their not useful / don't have use-case related to "supporting `O0` is useful"?


Upfront, it seemed peculiar to handle only one optimization level.  After more thought, the whole idea of mixing -O0 and LTO seems wrong.  Sorry, should have signaled that I had changed my mind about it.

>>>> Optnone does not equal -O0.  It is a debugging aid for the programmer, because debugging optimized code sucks.  If you have an LTO-built application and want to de-optimize parts of it to aid with debugging, then you can use the pragma, as originally intended.
>>> 
>>> Having to modifying the source isn't friendly. Not being able to honor -O0 during LTO is not user-friendly.
>> 
>> IMO, '-O0' and '-flto' are conflicting options and therefore not deserving of special support.
> 
> You're advocating for *rejecting* O0 built module at link-time? We'd still need to detect this though. Status-quo isn't acceptable.
>  Also, that's not practicable: what if I have an LTO static library for which I don't have the source, now if I build my own file with -O0 -flto I can't link anymore.

No, I'm saying they are conflicting options on the same Clang command line.
As long as your linker can handle foo.o and bar.bc on the same command line, not a problem.  (If your linker can't handle that, fix the linker first.)

>> In my experience, modifying source is by far simpler than hacking a build system to make a special case for compiler options for one module in an application.  (If you have a way to build Clang with everything done LTO except one module built with -O0, on Linux with ninja, I would be very curious to hear how you do that.)
> 
> Static library, separated projects, etc.
>  We have tons of users...

Still waiting.  Your up-front use case was about de-optimizing a module to assist debugging it within an LTO-built application, not building entire projects one way versus another.  If that is not actually your use case, you need to start over with the correct description.

>>>>   I don't think `-c -O0` should get this not-entirely-O0-like behavior.
>>> 
>>> What is "not-entirely"? And why do you think that?
>> 
>> "Not entirely" means that running the -O0 pipeline, and running an optimization pipeline but asking some subset of passes to turn themselves off, does not get you the same result.  And I think that because I'm the one who put 'optnone' upstream in the first place.  The case that particularly sticks in my memory is the register allocator, but I believe there are passes at every stage that do not turn themselves off for optnone.
> 
> That's orthogonal: you're saying we are not handling it correctly yet, I'm just moving toward *fixing* all these.

It's not orthogonal; that's exactly how 'optnone' behaves today.  If you have proposed a redesign of how to mix optnone and non-optnone functions in the same compilation unit, in some way other than what's done today, I am not aware of it; can you point to your proposal?


https://reviews.llvm.org/D28404