Dale Johannesen wrote:
So I guess question 1 is, Mark, do you feel negatively enough about this
feature to block its acceptance in mainline?
I'm not sure that I *could* block it, but, no, I don't feel that negatively.
Well, in theory nobody can block anything (although some people's posts suggest
they don't understand this). In practice if you or another GWM objects to something,
nobody else is going to override you and approve it.
I tried to address your other questions in my previous message, but:
I think that a #pragma (or attribute) that affects only optimization options is less problematic than generic option processing (.e.g, flag_writable_strings, as in the email you reference).
I do think that you need to clearly document how inlining plays with this. In particular, if you inline a -O2 function into a -O0 function, what happens? (My suggestion would be that the caller's optimization pragmas win.)
Agree. (And documentation will be written.)
Also, you should document what set of optimization options can be specified. I think it should only be ones that do not change the ABI; things like -O2, or turning off particular passes are OK, while options that change calling conventions, etc., should be disallowed.
Agree.
Also, you need to say what happens in the situation where the user has done "-O2 -fno-gcse" and the #pragma now says "-O2". Does that reenable GCSE? (I think it should.)
Yes.
what's the granularity of this #pragma? Function-level, I hope?
That's what I assumed. Anything finer than that is insane. :-)
Actually there are cases where it makes sense: you could ask that a particular call be
inlined, or a particular loop be unrolled N times. However, I'm not planning to do anything
finer-grained than a function at the moment. Certainly for optimizations that treat a whole
function at once, which is most of them, it doesn't make sense.
