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

[chris jefferson <caj at cs dot york dot ac dot uk>]

Gabriel Dos Reis wrote:

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

To fix the existing code, it's actually very easy to nuke the extra 
parameters, we just remove them!

So:(for example: note this isn't actual compilable code!)

template<class T, class Val, class ItCategory>
T __find(T start, T end, Val value, ItCategory)
{..}

becomes:

template<class T, class Val, class ItCategory>
T __find(T start,T end, Val value)

and instead of calling:

__find(start,end,value,iterator_traits<start>::category)

call

__find<iterator_traits<start>::category>(start,end,value)

this appears from some tests to have exactly the same properties, but 
saves the extra operand. Unfortunatly this atually doesn't help with the 
newest ones I've added, as in some cases we care about the actual 
objcet,and in some cases it is an empty class, so this won't work...

> A pattern that I believe is recurrent with many uses of empty classes,
> is that arguments of such types tend to be "trailing".
>
>  
I think I understand what you are saying below. What I wondered however 
in the "stack based" case ou are suggesting that we don't increase the 
stack pointer as far as we did before? Or just (as I thought you would 
have done) increase the stack pointer as far as it was done previously, 
but just make the compiler never write to the place where empty_struct 
is passed, and never read from it (because of course it never should). 
This on one hand wastes a little stack space but on the other hand seems 
to be (famous last words) like it should never break anything, as 
nothing should ever read the value of an empty struct, except perhaps to 
copy it because it is stupid...

Chris