Re: [C++ PATCH] Don't create an INTEGER_CST for aggregates (empty structs)

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Paolo Carlini <pcarlini@suse.de> writes:

| Gabriel Dos Reis wrote:
| 
| >There is no way (C++-wise and ABI-wise) you tell when a value of empty
| >class has been loaded in a register or not.  An empty class does not
| >contain any data:  Everything is in the type -- which is a purely
| >compile-time construct.
| >
| Thanks Gaby (and Andrew) for your clarifications about the C++
| front-end: I'm a novice, indeed, and appreciate that.
| 
| What I'm missing, now, but I don't think it's a purely front-end issue
| (I'm also implicitly taking into account you message to the library
| reflector) is whether optimizers downstream, in the middle-end, can
| factor out the ABI prescriptions about argument passing. In other
| terms: if something can figure that there is *nothing* to pass,
| actually, neither in registers nor in stack! Is middle-end/20408
| really fixable on x86 or not?
| 
| If it's really impossible to optimize out the difference, maybe we
| have to live with it and go ahead anyway with the clean-ups that
| started the issue (in that case, the negative impact is small). If, on
| the other hand, it's only a matter of waiting for some optimizations
| to be implemented we have to *seriously* take care of that, making
| sure that the libstdc++-v3 development in that specific area doesn't
| proceed "too fast", assuming unreasonable optimizations.
| 
| Third possibility: a new attribute of sort (you suggested that, I
| think), but I'm not sure whether it's really doable: even an extension
| cannot be against the ABI, if the ABI is the real issue.
| 
| Yes, I'm confused: anyone willing to clarify??

I did not mean to confuse you.

I think there is some improvement that can be done without breaking
ABI -- well only the fact that program compiled with old version of V3
will silently break with new version of v3, but that is already
assumed for v7.

A pattern that I believe is recurrent with many uses of empty classes,
is that arguments of such types tend to be "trailing".

First consider the case of register-based CPUs.
If trailing parameter types are empty classes, then the compiler can
safely ignore loads of corresponding argument into registers when
calling the function.  The same holds if the argument was to be passed
by invisible reference (e.g. on SPARC v7/v8) and it is trailing.
That is safe because you cannot call a function if its parameter types
are not complete, so the sole function signature legible for calls
gives you all information you need.

Second, the case of stack-based CPUs, e.g. x86-like.
The caller does not need any push of such trailing empty class
arguments on stack -- and the callee knows it has no business trying
to pop such value.  Consequently adjustments need to be done for the 
stack frame "depth". 

In either case, that approximation is doable by the middle-end.  And I
think that would be a good start and a real improvement.
Please check with a middle-end expert.

-- Gaby