Hi Diego,
Jeff's point about our optimizers is also true. Nick, remember that
issue with MIPS optimizations you were discussing with Jeff a few days
ago? I didn't follow most of the details, but it involved ivopts and
sign issues. Could you send a summary?
Sure:
I was looking at how a
Nick Clifton wrote:
Hi Diego,
Jeff's point about our optimizers is also true. Nick, remember that
issue with MIPS optimizations you were discussing with Jeff a few days
ago? I didn't follow most of the details, but it involved ivopts and
sign issues. Could you send a summary?
Sure:
Kenneth Zadeck wrote on 08/15/06 11:57:
We should be looking at the back end to see where it cannot see what it
needs to see rather than trying to stop getting the middle end code into
a reasonable form.
You're confused. This is a middle-end mis-optimization. However, it is
true that we
On Tue, 2006-08-15 at 11:57 -0400, Kenneth Zadeck wrote:
Nick Clifton wrote:
Hi Diego,
Jeff's point about our optimizers is also true. Nick, remember that
issue with MIPS optimizations you were discussing with Jeff a few days
ago? I didn't follow most of the details, but it involved
Diego Novillo wrote:
Kenneth Zadeck wrote on 08/15/06 11:57:
We should be looking at the back end to see where it cannot see what it
needs to see rather than trying to stop getting the middle end code into
a reasonable form.
You're confused. This is a middle-end mis-optimization.
Kenneth Zadeck wrote:
Nick Clifton wrote:
Hi Diego,
Jeff's point about our optimizers is also true. Nick, remember that
issue with MIPS optimizations you were discussing with Jeff a few days
ago? I didn't follow most of the details, but it involved ivopts and
sign issues. Could you send
Mark Mitchell wrote:
Kenneth Zadeck wrote:
So, I guess my inclination would be to just write out the type
information now, and thereby avoid the dependency on fixing GIMPLE.
Please don't take this the wrong way, but this approach is the reason
GIMPLE is not flat/tupelized, not type
Daniel Berlin wrote on 08/14/06 09:04:
If this is a cleanup we actually want done, IMHO, we should do it first.
Agreed. This is a good opportunity for us to design a GIMPLE type
system. Besides the obvious space savings and cleanliness, it is also
needed to remove
Daniel Berlin wrote:
Mark Mitchell wrote:
Kenneth Zadeck wrote:
So, I guess my inclination would be to just write out the type
information now, and thereby avoid the dependency on fixing GIMPLE.
Please don't take this the wrong way, but this approach is the reason
GIMPLE is not
Diego Novillo wrote:
If we had a GIMPLE type-system, we could allow the implicit type
conversions.
Right, I was trying to make this point earlier, but not being clear. It
doesn't matter if every last conversion is explicit, as long as there
are clear rules about where conversions may be
Hi,
On Mon, 14 Aug 2006, Mark Mitchell wrote:
pressure build on some set of infrastructure until it has been painfully
obvious for some amount of time that it has to change. (In my
experience, the same thing happens in developing proprietary software;
convincing product management to let
Diego Novillo writes:
Diego Agreed. This is a good opportunity for us to design a GIMPLE type
Diego system. Besides the obvious space savings and cleanliness, it is also
Diego needed to remove lang_hooks.types_compatible_p.
And this last statement is the key point. We can and
Michael Matz wrote:
pressure build on some set of infrastructure until it has been painfully
obvious for some amount of time that it has to change. (In my
experience, the same thing happens in developing proprietary software;
convincing product management to let you spend significant time
David Edelsohn wrote:
Diego Novillo writes:
Diego Agreed. This is a good opportunity for us to design a GIMPLE type
Diego system. Besides the obvious space savings and cleanliness, it is also
Diego needed to remove lang_hooks.types_compatible_p.
And this last statement
On Aug 14, 2006, at 9:52 AM, Michael Matz wrote:
How true :) Nevertheless the goals for the FSF GCC should IMHO be
purely based on rather technical arguments and considerations, not
the drive by paying customers.
:-) I'd of course argue that a compiler with no customers (I'd use
the
Dan == Daniel Berlin [EMAIL PROTECTED] writes:
Dan I do not *fault* Diego (and others) for the decision to get a
Dan prototype of GIMPLE/tree-ssa first, and clean it up later.
FWIW my experience writing a front end was that trees remain weird to
work with -- sometimes fixing type compatibility
Kenneth Zadeck wrote:
I am modifying my code so that their is a preprocessor flag,
STUPID_TYPE_SYSTEM that either writes or does not write the redundant
type nodes.
I think the macro name is needlessly negative, but I think the idea is
fine. Could we just say something like
Kenneth Zadeck wrote:
I have had some discussions with Honza and Diego about the type
consistency at the gimple level. They told me that Andrew was in the
process of making gimple properly type consistent.
I think that there is widespread consensus that GIMPLE should ideally be
type
On Sun, 2006-08-13 at 10:53 -0700, Mark Mitchell wrote:
(In my opinion, it doesn't really matter if MODIFY_EXPR is treated as
doing an implicit conversion; the important thing is that the set of
places where implicit conversions are performed be both limited and
documented. If we save tons
On Sun, 2006-08-13 at 12:55 -0600, Jeffrey Law wrote:
Thus the existence of some implicit type conversions. IIRC the
places where these occur or occurred at one time or we pondered
allowing are:
1. MODIFY_EXPRs where the RHS can be implicitly converted to the
type of the LHS and
On Sun, 2006-08-13 at 10:53 -0700, Mark Mitchell wrote:
I think this is a question of priorities. It's relatively
straightforward to fix the compiler to generate type-consistent GIMPLE:
you write consistency-checking routines and then you just fix all the
problems that arise, by inserting
On 8/11/06, Kenneth Zadeck [EMAIL PROTECTED] wrote:
Mark,
I have had some discussions with Honza and Diego about the type
consistency at the gimple level. They told me that Andrew was in the
process of making gimple properly type consistent.
I just wanted to point out how this effects
Richard Guenther wrote:
On 8/11/06, Kenneth Zadeck [EMAIL PROTECTED] wrote:
Mark,
I have had some discussions with Honza and Diego about the type
consistency at the gimple level. They told me that Andrew was in the
process of making gimple properly type consistent.
I just wanted to point
On 8/11/06, Kenneth Zadeck [EMAIL PROTECTED] wrote:
Richard Guenther wrote:
On 8/11/06, Kenneth Zadeck [EMAIL PROTECTED] wrote:
Mark,
I have had some discussions with Honza and Diego about the type
consistency at the gimple level. They told me that Andrew was in the
process of making
Richard Guenther wrote:
On 8/11/06, Kenneth Zadeck [EMAIL PROTECTED] wrote:
Richard Guenther wrote:
On 8/11/06, Kenneth Zadeck [EMAIL PROTECTED] wrote:
Mark,
I have had some discussions with Honza and Diego about the type
consistency at the gimple level. They told me that Andrew
Some historical discussions as a refresher:
http://gcc.gnu.org/ml/gcc/2005-02/msg00324.html
http://gcc.gnu.org/ml/gcc/2004-09/msg01562.html
http://gcc.gnu.org/ml/gcc/2003-12/msg01264.html
David
David Edelsohn wrote:
Some historical discussions as a refresher:
http://gcc.gnu.org/ml/gcc/2005-02/msg00324.html
I honestly don't have the doc anymore, but i did send it to some people
before i stopped working on it.
I had guessed that nobody would really care enough to review the
27 matches
Mail list logo
