On Fri, Sep 23, 2016 at 10:59:12AM +0200, Richard Biener wrote:
> On Fri, 23 Sep 2016, Jakub Jelinek wrote:
>
> > On Fri, Sep 23, 2016 at 08:55:02AM +0200, Richard Biener wrote:
> > > While I agree with the goal to reduce the number of static constructors
> > > esp. the vNULL cases I disagree with. This is just introducing
> > > undefined behavior (uninitialized object use), and in case we end up
> > > making vNULL not all-zeros it's bound to break. So IMHO your patch
> > > is very much premature optimization here.
> >
> > No, there is no undefined behavior, and we rely on the zero initialization
> > in > 100 cases, see
> > grep '\(^\|static \)vec \?<.*;' *.c *.cc */*.c ada/*/*.c | grep -v '\*'
> > or anywhere where we have vec part of a struct that we allocate cleared or
> > clear after allocation.
> > The thing is, vec is (intentionally) a POD, thus doesn't have a ctor,
> > and the = vNULL "construction" is
> > template <typename T, typename A, typename L>
> > operator vec<T, A, L> () { return vec<T, A, L>(); }
> > actually clearing of the vector. If we ever wanted to initialize vec to
> > something not-all-zeros, we'd actually need to turn it into non-POD and add
> > ctor.
> >
> > I'm attaching 3 further patches (not bootstrapped/regtested yet), which:
> > 1) adds constexpr keyword for C++11 + to the vNULL operator, this seems to
> > be enough to get rid of the runtime initialization, both in the
> > tree-ssa-sccvn.o case with _ZGV var and e.g. in passes.c get rid of
> > _Z41__static_initialization_and_destruction_0ii ctor
>
> Really? We have
>
> extern vnull vNULL;
vNULL is not a vec (after all, vec is a template, so there can't be a single
object), just a dummy object with a conversion operator template which
value-initializes an unnamed vec temporary and the assignment copies it into
the variable.
Anyway, I'll file 2 PRs, one for the file scope static initialization
optimization, another for the local static.
Jakub
