[PATCH] D28404: IRGen: Add optnone attribute on function during O0
Mehdi AMINI via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Mon Jan 9 13:59:58 PST 2017
mehdi_amini added a comment.
In https://reviews.llvm.org/D28404#640284, @probinson wrote:
> 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.
You just haven't articulated 1) why it is wrong and 2) what should we do 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.)
You just wrote above that " mixing -O0 and LTO " is wrong, *if* I were to agree with you at some point, then I'd make it a hard error.
>>> 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.
Waiting for what?
We have use-cases, I gave you a few (vendor static libraries are one). Again, if you think it is wrong to support O0 and LTO, then please elaborate.
>>>>> 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?
I don't follow: IMO if I generate a module with optnone and pipe it to `opt -O3` I expect no function IR to be touched. If it is not the case it is a bug.
https://reviews.llvm.org/D28404
More information about the cfe-commits
mailing list