[Bug tree-optimization/59875] Missed unrolling opportunity

[Bug tree-optimization/59875] Missed unrolling opportunity

[glisse at gcc dot gnu.org]

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

Marc Glisse <glisse at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-01-19
            Summary|Weak symbols in glibc       |Missed unrolling
                   |prevent optimizations       |opportunity
     Ever confirmed|0                           |1
           Severity|trivial                     |normal

--- Comment #1 from Marc Glisse <glisse at gcc dot gnu.org> ---
(note that your new/delete prototypes are the C++03 ones, you should change
them for C++11)

I don't think it has anything to do with glibc or weak. If I patch
tree-ssa-loop-ivcanon.c (couldn't find a sufficient option or parameter) to
convince the compiler that it is ok to unroll the loop although it isn't an
inner loop and it contains calls on the "hot" path, it manages to optimize foo
to nothing.

gcc-4.4 (if we tweak the example so it compiles) did unroll the loop, but only
optimized away the test for the last element of the array.

It would also be possible for the compiler to notice that all array elements
are the same and thus any access (in range) will yield the same value, but that
seems more specialized.

[Bug tree-optimization/59875] Missed unrolling opportunity

[josephlawrie at hotmail dot com]

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

--- Comment #2 from josephlawrie at hotmail dot com ---
(In reply to Marc Glisse from comment #1)

> I don't think it has anything to do with glibc or weak. If I patch
> tree-ssa-loop-ivcanon.c (couldn't find a sufficient option or parameter) to
> convince the compiler that it is ok to unroll the loop although it isn't an
> inner loop and it contains calls on the "hot" path, it manages to optimize
> foo to nothing.

Am I correct in understanding this would not be possible without -fno-weak or
when linking dynamically? In those cases, the function of delete could not be
know when optimizingm, surely?

[Bug tree-optimization/59875] Missed unrolling opportunity

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to josephlawrie from comment #2)
> (In reply to Marc Glisse from comment #1)
> Am I correct in understanding this would not be possible without -fno-weak
> or when linking dynamically? In those cases, the function of delete could
> not be know when optimizingm, surely?

My comments were for the version where you uncomment the definitions of new and
delete:

#include <array>
#include <cassert>
#include <cstdlib>

struct P {
    P() : _value(0) {}
    ~P() { if(_value) free(_value); }
   char *_value;
};

int main() {
  if(std::array<P, 4>().size() != 4)
    assert(false);
}


You can look at what happens if you change the size of the array to 1, which
removes the unrolling issue. After unrolling, you get either 4 calls to
operator delete(0), or nothing if you provided your definition of delete.

To let the compiler know that you want the standard operator delete (which does
nothing on 0), I am not sure what should be done. It is a different issue,
which you would need to ask about in a separate PR. The easiest is probably to
use -flto (it has to be used all the way, in particular when building
libsupc++). I think libstdc++ should provide an option to get inline
definitions of those functions (I know the standard forbids them to be inline),
possibly even omitting the new_handler code.

[Bug tree-optimization/59875] Missed unrolling opportunity

[josephlawrie at hotmail dot com]

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

--- Comment #4 from josephlawrie at hotmail dot com ---
> To let the compiler know that you want the standard operator delete (which
> does nothing on 0), I am not sure what should be done. It is a different
> issue, which you would need to ask about in a separate PR. 

> I think libstdc++ should provide an option to get
> inline definitions of those functions (I know the standard forbids them to
> be inline), possibly even omitting the new_handler code.

Thank you - I realise I was originally very unclear, but being able to get "an
inline version" was the intention of posting this hear. Basically link time
optimization (inconvienient) or static linking (also inconvenient) are the only
correct solitions, as others would make the functions non-replacable. 

My concern was that being unable to specify default delete could prevent
optimization in some cases (even when building statically), but according to
you this is not the case in the example, as it is the loop unrolling that
prevents the optimization here. Thank you.

[Bug tree-optimization/59875] Missed unrolling opportunity

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59875

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Reduced testcase:
```
void foo1()
{
  char *a[4] = {nullptr, nullptr, nullptr, nullptr};
  char **b = &a[4];
  while (b!=&a[0])
  {
        b--;
        if (*b) __builtin_free(*b);
  }
}
```

size: 10-3, last_iteration: 10-3
  Loop size: 10
  Estimated size after unrolling: 18
Not unrolling loop 3: contains call and code would grow.


There is another bug similar to this where we could decrease the cost slightly
if we know that a[i] is stored above and might eliminate the branch.