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

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

[dann at godzilla dot ics dot uci dot edu]

For the function 
int foo (int a)
{
   if (a) return 1;
   else return 0;  
}

the .original dump is: 
{
   if (a != 0)
      return <return-value> = 1;
   else
       return <return-value> = 0;
   
}

It is more space efficient to translate the "if" to "if (a) "

It might even be a good idea to fold if (a != 0) to if (a) during optimization.

-- 
           Summary: [tree-ssa] don't generate if (a != 0) for if (a)
           Product: gcc
           Version: 3.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dann at godzilla dot ics dot uci dot edu
                CC: gcc-bugs at gcc dot gnu dot org


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

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-05-20 01:07 -------
The reason why this is not done this way as it would prevent some optimizations from happening and it 
is not the way it is done for most targets (yes x86 is the exception here).  Anywas this function should 
be optimized to "a==0" but is not as the return expressions are not merged to.

-- 


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

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

[dann at godzilla dot ics dot uci dot edu]

------- Additional Comments From dann at godzilla dot ics dot uci dot edu  2004-05-20 01:59 -------
(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? 
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. 

> 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? 

-- 


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

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-05-20 12:44 -------
(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).

> 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).
 
> > 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).

-- 


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

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

[dann at godzilla dot ics dot uci dot edu]

------- 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

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-07-05 22:31 -------
I think this is really just a dup of bug 15618.

But COND_EXPR for gimple requires its first argument (the conditional) be of type boolean_type.

-- 


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

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-07 22:20 -------
Closing as a dup of bug 15618.

*** This bug has been marked as a duplicate of 15618 ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


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