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.
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-
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
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
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?
>
>
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 gc
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 EXPLICIT_TYPE_
> "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 comp
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 term
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
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
> 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
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 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 impl
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 f
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 lang_hooks.types_compatibl
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 con
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 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
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 ton
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
>
> 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.
The last patch I wrote for this is located at:
http://gcc.gnu.org/ml/gcc-patches/2006-06/msg0
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 p
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
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
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
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
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 encodi
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 encoding gimple into dwarf.
If the gimple is type consistent,
29 matches
Mail list logo
