> 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 an
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
Respected Sir
I am a M.E.Computer science student and doing project on induction variable
optimization.
Therefore i am reading the file tree-ssa-loop-ivopts.c of gcc-4.0.2 to know
about what have implemented in that.
Is there any other way to know about what have implemented yet and in
gcc-4.0.2
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
[EMAIL PROTECTED] wrote on 06/11/2006 03:34:27:
> Respected Sir
>
> I am a M.E.Computer science student and doing project on induction
variable
> optimization.
>
> Therefore i am reading the file tree-ssa-loop-ivopts.c of gcc-4.0.2 to
know
> about what have implemented in that.
>
> Is there any
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 <[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 there are so many th
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
Unfortunately there's no way to specify alignment attribute of pointers in
GCC - the syntax was allowed in the past but not really supported
correctly, and then entirely disallowed (by this patch
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02284.html). This issue was
discussed in details in these
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
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
On 11/4/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
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
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
> On 11/4/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
> >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 too
> 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
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
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 addre
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_
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 Nov 4, 2006, at 11:00 AM, Michael James wrote:
Does anyone have a suggestion?
#define SSE __attribute__((aligned (16)))
typedef float matrix_sub_t[1024] SSE;
typedef matrix_sub_t matrix_t[100];
matrix_t a, b, c;
void calc(matrix_sub_t * restrict ap,
matrix_sub_t * restrict bp,
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
Hello,
> I am a M.E.Computer science student and doing project on induction variable
> optimization.
>
> Therefore i am reading the file tree-ssa-loop-ivopts.c of gcc-4.0.2 to know
> about what have implemented in that.
>
> Is there any other way to know about what have implemented yet and in
> g
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_
> > 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
Hello Dorit,
Thank you for the list of references.
What I gathered from reading this is that alignment attributes applied
to the base element of an array are causing problems for other
legitimate uses of this attribute. It is basically stupid to specify
the base type of an array be aligned becau
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
Dear all,
Although I understand what is the difference between dg-do compile and
dg-do assemble, I have noticed that there are many testcases that use
either dg-compile or dg-do assemble and do nothing with the output.
Thus, I would like to know:
Is it faster {dg-do compile} or {dg-do assemble}
> Although I understand what is the difference between dg-do compile and
> dg-do assemble, I have noticed that there are many testcases that use
> either dg-compile or dg-do assemble and do nothing with the output.
> Thus, I would like to know:
>
> Is it faster {dg-do compile} or {dg-do assemble}
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
I am going to try to fix:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29721
Which is a problem where a %lo relocation gets separated from its
corresponding %hi.
What is the mechanism that tries to prevent this from happening? And
where is it implemented?
Thanks,
David Daney
Hello all,
Looking at a .md file of a backend it there a way to know whether a
target supports long long
Should i look for patterns with machine mode DI?
Is there some other way?
Thanks in advance for the help.
Regards,
Shafi
31 matches
Mail list logo
