Jan Hubicka wrote on 11/07/06 05:07:
-O3 enables inlining, unswitching and GCSE after reload. How those
change semantics of the program?
Bah, I was convinced we were switching on -ffast-math at -O3. Never mind.
> Brooks Moses wrote on 11/06/06 17:41:
>
> >Is there a need for any fine-grained control on this knob, though, or
> >would it be sufficient to add an -O4 option that's equivalent to -O3 but
> >with no optimization throttling?
> >
> We need to distinguish two orthogonal issues here: effort and e
Brooks Moses wrote on 11/06/06 17:41:
Is there a need for any fine-grained control on this knob, though, or
would it be sufficient to add an -O4 option that's equivalent to -O3 but
with no optimization throttling?
We need to distinguish two orthogonal issues here: effort and enabled
transfor
Kenneth Zadeck wrote:
The problem with trying to solve this problem on a per pass basis rather
than coming up with an integrate solution is that we are completely
leaving the user out of the thought process.
There are some uses who have big machines or a lot of time on their
hands and want the d
Kenneth Zadeck wrote on 11/06/06 12:54:
I am not saying that my original proposal was the best of all possible
worlds, but solving hacking things on a pass by pass or pr by pr basis
is not really solving the problem.
I don't think it's a hackish approach. We have policy setting at the
high le
The problem with trying to solve this problem on a per pass basis rather
than coming up with an integrate solution is that we are completely
leaving the user out of the thought process.
There are some uses who have big machines or a lot of time on their
hands and want the damn the torpedoes full
Andrew MacLeod wrote:
> On Sat, 2006-11-04 at 15:17 -0500, Kenneth Zadeck wrote:
>
>> ld.
>>
>
>
>> However, I think that before anyone starts hacking anything, we should
>> come to a consensus on an overall strategy and implement something
>> consistent for the entire compiler rather t
On Sat, 2006-11-04 at 15:17 -0500, Kenneth Zadeck wrote:
> ld.
>
> However, I think that before anyone starts hacking anything, we should
> come to a consensus on an overall strategy and implement something
> consistent for the entire compiler rather than attack some particular
> pass in a manne
Kenneth Zadeck wrote on 11/04/06 15:17:
1) defining the set of optimizations that need to be skipped. 2)
defining the set of functions that trigger the special processing.
This seems too simplistic. Number of variables/blocks/statements is a
factor, but they may interact in ways that are dif
The gcc developers have been very cooperative over the years in
working to solve problems that I've had in compiling large machine-
generated programs. For example, when gcse was disabled for large
flow flow graphs in 2000, the warn_disabled_optimization flag was
added at my suggestion. As
On 11/5/06, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > Tree alias analysis can partially disable itself though:
>
> No, it can't. Tree alias representation can :)
I presume you're thinking of the pass that performs the analysis, while I was
more thinking of the global machinery; my understand
> > Tree alias analysis can partially disable itself though:
>
> No, it can't. Tree alias representation can :)
I presume you're thinking of the pass that performs the analysis, while I was
more thinking of the global machinery; my understanding is that the machinery
will not be able to disambi
On 11/5/06, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> AFAIK not one of the tree optimizers disables itself, but perhaps we
> should. The obvious candidates would be the ones that require
> recomputation of alias analysis, and the ones that don't update SSA
> info on the fly (i.e. require update_
Steven Bosscher wrote:
On 11/5/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
I would like to point out that the central point of my proposal was to
have the compilation manager be the process that manages if an
optimization is skipped or not rather than having each pass make a
decision on it's o
On 11/5/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
I would like to point out that the central point of my proposal was to
have the compilation manager be the process that manages if an
optimization is skipped or not rather than having each pass make a
decision on it's own. If we have a centra
On 11/5/06, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> AFAIK not one of the tree optimizers disables itself, but perhaps we
> should. The obvious candidates would be the ones that require
> recomputation of alias analysis, and the ones that don't update SSA
> info on the fly (i.e. require update_
Paolo Bonzini wrote:
Kenneth Zadeck wrote:
I think that it is time that we in the GCC community took some time to
address the problem of compiling very large functions in a somewhat
systematic manner.
While I agree with you, I think that there are so many things we are
already trying to
Eric Botcazou wrote:
>> AFAIK not one of the tree optimizers disables itself, but perhaps we
>> should. The obvious candidates would be the ones that require
>> recomputation of alias analysis, and the ones that don't update SSA
>> info on the fly (i.e. require update_ssa, which is a horrible compi
> AFAIK not one of the tree optimizers disables itself, but perhaps we
> should. The obvious candidates would be the ones that require
> recomputation of alias analysis, and the ones that don't update SSA
> info on the fly (i.e. require update_ssa, which is a horrible compile
> time hog).
Tree ali
:
> >>> >> I think that it is time that we in the GCC community took some
> >>> time to
> >>> >> address the problem of compiling very large functions in a somewhat
> >>> >> systematic manner.
> >>> >>
> >>>
On 11/5/06, Richard Guenther <[EMAIL PROTECTED]> wrote:
> I lean to leave the numbers static even if they do increase as time goes
> by. Otherwise you get two effects, the first optimizations get to be
> run more, and you get the wierd non linear step functions where small
> changes in some upst
e that we in the GCC community took some
>> time to
>> >> address the problem of compiling very large functions in a somewhat
>> >> systematic manner.
>> >>
>> >> GCC has two competing interests here: it needs to be able to provide
>> >
On Nov 5, 2006, at 08:46, Kenneth Zadeck wrote:
The thing is that even as memories get larger, something has to give.
There are and will always be programs that are too large for the most
aggressive techniques and my proposal is simply a way to gracefully
shed
the most expensive techniques as
Kenneth Zadeck wrote:
I actually think that you small talk example is the exception and not
the rule. I would guess that the vast majority of very large functions
are machine generated simulations where the optimizer most likely
provides little benefit.
Wouldn't it be best to base this discus
Paolo Bonzini <[EMAIL PROTECTED]> writes:
[...]
| Unlike the authors of other VM's, I have no problem writing code so
| that the *latest* version of GCC will do its best, instead of
| complaining that GCC compiles my code worse on every release. So, I
You gave some examples; those are not the o
Paolo Bonzini <[EMAIL PROTECTED]> writes:
| Kenneth Zadeck wrote:
| > I think that it is time that we in the GCC community took some time to
| > address the problem of compiling very large functions in a somewhat
| > systematic manner.
|
| While I agree with you, I think that th
Kenneth Zadeck writes:
> Paolo Bonzini wrote:
> >
> >> While I agree with you, I think that there are so many things we
> >> are already trying to address, that this one can wait. I think
> >> we've been doing a very good job on large functions too, and I
> >> believe that authors of very la
Paolo Bonzini wrote:
>
>> While I agree with you, I think that there are so many things we are
>> already trying to address, that this one can wait. I think we've
>> been doing a very good job on large functions too, and I believe that
>> authors of very large functions are just getting not only w
While I agree with you, I think that there are so many things we are
already trying to address, that this one can wait. I think we've been
doing a very good job on large functions too, and I believe that authors
of very large functions are just getting not only what they deserve, but
actuall
> I think that it is time that we in the GCC community took some time to
> address the problem of compiling very large functions in a somewhat
> systematic manner.
>
> GCC has two competing interests here: it needs to be able to provide
> state of the art optimization for mode
Kenneth Zadeck wrote:
I think that it is time that we in the GCC community took some time to
address the problem of compiling very large functions in a somewhat
systematic manner.
While I agree with you, I think that there are so many things we are
already trying to address, that this one can
Richard Guenther wrote:
> On 11/4/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>> Richard Guenther wrote:
>> > On 11/4/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>> >> I think that it is time that we in the GCC community took some
>> time to
&
On 11/4/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
Richard Guenther wrote:
> On 11/4/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>> I think that it is time that we in the GCC community took some time to
>> address the problem of compiling very large functions
Richard Guenther wrote:
> On 11/4/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>> I think that it is time that we in the GCC community took some time to
>> address the problem of compiling very large functions in a somewhat
>> systematic manner.
>>
>> GC
On 11/4/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
I think that it is time that we in the GCC community took some time to
address the problem of compiling very large functions in a somewhat
systematic manner.
GCC has two competing interests here: it needs to be able to provide
state
I think that it is time that we in the GCC community took some time to
address the problem of compiling very large functions in a somewhat
systematic manner.
GCC has two competing interests here: it needs to be able to provide
state of the art optimization for modest sized functions and it needs
36 matches
Mail list logo
