This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: type consistency of gimple

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-consistent, in the sense that (as you say) the only places where
types change is via explicit type-casts (e.g., NOP_EXPRs).  The same
optimization that you want to perform at the LTO level (i.e., not
writing out types for every nodes) is also one that would pay off in
terms of memory savings at the TREE level.

(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 of TREE nodes by saying that MODIFY_EXPR is
defined to do an implicit conversion, as if the right-hand side had a
NOP_EXPR to convert it to the type of the left-hand side, then that
might be a perfectly valid memory optimization on TREE.)

So, the question is one of timing: do we build LTO to work with the
current not-type-consistent GIMPLE, or do we fix the compiler to
generate type-consistent GIMPLE first and then go on to LTO?

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 explicit type-conversions at the
source of the offending inconsistency.  However, while straightforward,
that's probably person-months of effort.

>From an engineering point of view, it would probably be best to fix
GIMPLE first; that has other positive side-effects, and it would avoid
doing LTO work that might have to be undone.

However, from a project-management point of view, it might be best to go
for proof-of-concept on LTO first, writing out the types for nodes
explicitly.  I would assume that this wouldn't be a lot of additional
effort; i.e., while it will waste a lot of space, it won't waste a lot
of programmer time.

You could also strike a middle ground: write the consistency checker
(Danny may have already done this) as a separate pass and put it on the
LTO branch.  Run it before writing out LTO information.  If the input is
inconsistent, abort; otherwise, write out LTO information.  That lets
you write out the more compact representation, but still avoid trying to
fix all of GIMPLE right now.  (You just have to fix whatever is required
for proof-of-concept programs to work.)  It does mean, though, that
you're essentially committing to the type-safety work before we can make
LTO part of mainline, which is probably adding several person-months to
the overall project.  Or else you have to assume that you may have to go
back and write out the type information later, in order to get LTO into

So, I guess my inclination would be to just write out the type
information now, and thereby avoid the dependency on fixing GIMPLE.

Mark Mitchell
(650) 331-3385 x713

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]