[Bug tree-optimization/15547] [tree-ssa] don't generate if (a != 0) for if (a)

["dann at godzilla dot ics dot uci dot edu" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From dann at godzilla dot ics dot uci dot edu  2004-05-20 17:15 -------
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > The reason why this is not done this way as it would prevent some
> > optimizations from happening 
> > 
> > What are those optimizations? 
> 
> PHI-OPT that was just added which optimizes:
> if (a!=0) b = a; else b = 0; into b = a; (which does show up in GCC).

You mean that this was to be represented as: 
if (a) b = a; else b = 0; 

the optimization would not be performed? 

> > Code like this is generated during compilation, (try for example PR8361) and
> > look in any of the dumps, there are a lot of "if (VARIABLE)" occurences. 
> > If the optimizers have problems with this, then it might be better not to
> > generate such code, or make sure that the optimizers can deal with it. 
> 
> But the RTL level has the exactly the same thing as the tree level as if(a) is
converted to compare a to 0 
> and the branch so it does not matter in mind and actually will only help in
memory savings (but then 
> again if constants were more shared that would help more than this would).

The RTL should not matter at this point. 

if (a) and if (a != 0) have the same meaning, and they are BOTH generated by the
compiler. 
My point was that if (a) is more memory efficient, so it would proably be better
to generate that form. 

If it is indeed true what you say that some optimizers don't deal with the 
"if (a)" form very well, then it's probably better to avoid that form, or teach
the optimizers to deal with it. 

> > > and it is not the way it is done for most targets (yes x86 is the exception
> > here).  
> > 
> > Can you please explain what you mean by this? 
> 
> Yes, most targets explicitly compare against 0
> unlike x86 where it just uses the test instruction).

Oh, I don't think this is relevant to what I was trying to say, the expanders
can generate the RTL needed for a machine from both forms. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15547