Problem with __gmp_expr

[Marc Glisse]

On Sat, 18 Jan 2014, Niels Möller wrote:

> Marc Glisse <marc.glisse at inria.fr> writes:
>
>> Currently, we store references (pointers) to the
>> arguments (except for builtin types like int or double), and in
>> particular an expression can hold a reference to another expression
>> that holds references to etc. This way each expression object is
>> small. With the change, instead of having a reference to another
>> expression, we know embed a copy of that other expression (only true
>> GMP variables are not copied and still held by reference).
>
> I was under the impression that these expression objects never exist at
> run time, it's only a way to get the template machinery to generate the
> right code? But then there are some problems if they are actually
> constructed?

It depends what you call "exist". In principle, they do exist at runtime, 
and indeed when you compile with -O0 they do. However if the compiler 
optimizes perfectly and users don't write "bad" code, they are optimized 
away and don't have a physical existence at runtime. But the behavior of 
the program is the same as if they did exist (compiler optimizers preserve 
that), and there is nothing wrong (except for performance) in constructing 
them.

>> Expression objects can now be rather large, and we copy them around
>> quite a bit. On the other hand, there are fewer indirections, which
>> may be why my gcc liked it. Ideally, it shouldn't matter, the compiler
>> should optimize all that away. In practice, it may not perfectly
>> finish the job sometimes.
>
> To me, optimizing the size of objects which normally shouldn't exist at
> all at runtime, doesn't seem very important.

Indeed. But that's not the only point. If I test with g++-4.4 instead of 
4.8, both .o have roughly the same size, and the patched gmpxx.h version 
is the one that is now missing an optimization (it doesn't notice at 
compile-time that x in x>=0 is always 1). It is important to known if 
which version works best changes with every gcc release or if there is 
some consistency. Latest clang seems to like the patch, and Intel doesn't 
care.

-- 
Marc Glisse