This is the mail archive of the gcc-patches@gcc.gnu.org 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: [tree-ssa,RFC/RFA?] fold-const versus GIMPLE types


In message <20031127231238.GI1906@kam.mff.cuni.cz>, Jan Hubicka writes:
 >Hi,
 >While working on gimple checking, I found out that many of problems I
 >orignally attributed to Jeff's tree_ssa_useless_type_conversion is
 >actually caused by fold-const.  The function accepts expression and
 >skips *any* nops (not only useless) and then it possibly construct new
 >expression with these arguments.  The new expression has wrong types
 >then.
I have had a feeling fold wasn't totally safe in this respect.  Or more
correctly, the rules for type safety within an expression have never
been adequately documented.  This has resulted in a hodge-podge of
conflicting behaviors in the folder and tree->rtl converters.

 >It seems to me that this is all broken.
fold as a whole is broken, though the situation is slowly improving.

 >In fact some of code paths
 >actually add convert call on the argument to re-invent stripped nops
 >apparently because this has caused problems somewhere and others does
 >not.
It would be nice if you could point out some of these specifically.  If
indeed they are regenerating NOPs because fold removed them, then we'd
like to be able to clean them up.

 >I think we can not add new converts, because it would turn GIMPLE into
 >non-GIMPLE by adding NOPS in arguments.
fold has a general problem in that it is not really aware of gimple and
that it's shared between gimple and non-gimple parts of the compiler.  That
is a fundamental problem that has already been discussed.  It's something
Roger, myself and probably others are going to tackle in the not terribly
distant future.


 >It seems to me that thinking on GIMPLE we don't need the skipping code
 >at all.  Thinking on GENERIC I am not at all sure what the grammar is
 >(are types supposed to match?  If so, we can not skip at all.  Are types
 >supposed to match modulo useless conversions like GIMPLE? THen attached
 >patch probably makes sense.  Are types allowed to be completely random?
 >Then gimplfiication should introduce the casts...)
You've hit on the fundamental problem.  Nobody knows.  This aspect of trees
to the best of my knowledge has never been documented.  I can make arguments
for either behavior (allow mis-matched operands or not).  I don't know which
is ultimately best.

 >The attached patch limits skipping only to useless type conversions.
 >This avoids about 80% of failures caught by my type checking code.
 >Does this sound like right thing to do?
Unsure.  Though certainly if we're going to use tree_ssa_useless_type_conversio
n
in the folder, then its name will have to change.


 >I've also included closely related change in c-typeck.c.  We need to
 >cast null_pointer_node assuming we insist on types to match in GENERIC
 >expressions.  Perhaps we need an exception here given exceptional
 >behaviour of NULL.
 >
 >The patch has been regtested and bootstrapped on i686-pc-gnu-linux and
 >x86_64-linux.
 >
 >Honza
 >
 >2003-11-28  Jan Hubicka  <jh@suse.cz>
 >	* c-typeck.c (convert_for_assignment): Cast NULL pointer to proper type
 >.
 >	* fold-const.c (fold): Strip only useless NOOP conversions.
I think we need to reach some conclusions about the type system before we
can know if this patch is the right direction or not.  And I'm somewhat
hesitant to muck around too much in the folder until we can actually sit
down and do the work to untangle its behavior to make it sane and safe
in the environments in which the folder can be used.

jeff


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