Sebastian Pop <[EMAIL PROTECTED]> writes: > I'd like to ask GCC users in general: how many are using these params?
We use them at my current employer, mainly to remove limits which were imposed to keep compile time under control. We have code which needs to run as fast as possible, for which compile time is, by comparison, irrelevant. So we drastically bump up the values for parameters like large-function-growth, inline-unit-growth, and max-pending-list-length. And it makes a huge difference in the generated code. But if I weren't there to give advice, I have low confidence that they would know about --param at all. > Why not having instead a set of flags that limit the resources allowed > for each "unnecessary" (to be defined...) part of the compiler? For > example, I'd like a guarantee that any tree level optimizer will stop > after at most 5 seconds and at most 300M of garbage: you'd say, > -fbudget-time=5 and -fbudget-space=300M instead of having to deal with > some obscure params. I have to agree that having 69 different parameters is a lot more useful for compiler developers than it is for compiler users. Some of the parameters, like large-function-growth, are fairly easy to understand and to use, particularly in conjunction with -Winline. Some of the other parameters, like lim-expensive or max-cse-path-length, are basically meaningless to anybody who hasn't studied the compiler in depth. I have to agree that setting time and space budgets would be much more useful for users than --param (not that we should remove --param, as it is useful for compiler developers). Or there is the idea which has been suggested several times, of permitting optimization to be specified along the orthogonal axes of time of compilation, speed of generated code, size of generated code, and debuggability. (While a time budget in seconds would lead to irreproducible results, a time budget expressed in a scale from fast to slow compilation time would not, and would be nearly as useful for users.) Ian
