This is the mail archive of the gcc@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] where to fix this?


> In message <20031223122751.GA2181@atrey.karlin.mff.cuni.cz>, Jan Hubicka writes
> :
>  >> My personal opinion is that constant folding should preserve the
>  >> type correctness of its transformations, calling "convert" on its
>  >> result if ever in doubt.  Unfortunately I think this is controversial,
>  >> with Jan arguing that this introduces so-called useless type conversions
>  >
>  >Actually it was not me arguing for this idea,  I was just trying to
>  >understand Jeff's plans in this area.  I was bit surprised by
>  >introducing the notion of useless type conversions, but I don't have
>  >very strong reasons for deciding about whether it is great idea or way
>  >to disaster :) I guess we will work out.
> Why would it be a surprise?  Some type conversions are strictly for the
> benefit of code which wants both operands of an expression to have precisely
> the same type.
> 
> However, there are a *ton* of cases where those type conversions are absolutely
> meaningless to the optimizers and code generators and in fact those
> conversions get in the way of optimizing code well because they hide
> equivalences.  
> 
> ie, if I have something like
> 
> x = (type) y;
> 
> If we can prove that the typecast is useless, then we can enter x = y into
> the const_and_copies table and copy propagate y into the uses of x.  Often
> this also makes "x" go away completely.

Yes, I do get that there are common patterns in the code this trick
solve very well.
> 
>  >Actually I think we are in the sync here.  I also think in favour of
>  >making convert to not produce NOP expr at all for useless type
>  >conversions.
> Sigh, you're still missing some fundamental issues here.
> 
>   1. You often can not tell if a given typecast is useless without some
>      additional context.

Hmm, there are definitly casts that are useless for "obvious" reasons
and casts that are useless for "nonobvious".  I think at the very moment
we skip only the obvious nops (where uselessness can be proved by
looking at inner and outer type), but I will keep in mind that you may
way to deal with more complex cases. 

I would like to be able to check that no obviously useless nops are in
the code, but with current design we remove all of them in early stages
but until late stages we manage to introduce them in some cases again.
> 
>   2. If you have convert not emit useless type conversions, then you have
>      to fix all the expanders and all the folders to handle operands which
>      may have different types.

We are currently feeding folders and expanders by expressions whithout
these useless NOPS, how it is different then?
>      
> 
>  >Unfortunately there are some cases where this holds for GIMPLE too.  You
>  >may see folding fix 6 I sent recently.  The SWITCH_EXPR of enum type
>  >must be represented as SWITCH_EXPR containign NOP to integer type
>  >containing enum type as switch expander would otherwise asume that not
>  >all integer values are possible.
> FYI, Richard may have just fixed this problem.

Yes, I just tested that.  Cool :)
>  >
>  >Then we can move whole existing fold into GIMPLE, strip out
>  >transformations that require nested trees and thus won't match on GIMPLE
>  >directly and re-implement them using walking the SSA graph as part of
>  >some expression reshaping passs.
> As has been stated before, fold needs a complete redesign.  And I really
> would prefer to have a single folder, not a gimple folder, then a 
> arbitrary tree folder, then language specific folders.  Ick.

How you want to make single folder do magically what you want?
(ie folding just what C standard says or folding as much as possible or
folding and preserving gimpleness).
I agree that the implementation should be shared as we don't want to
have every simple transformation 3 times.

Honza
> 
> jeff
> 
> Jeff


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