Missing qualifications

[Gabriel Dos Reis]

Chris Jefferson <caj@cs.york.ac.uk> writes:

| |
| | Hummm, I'm not sure to understand: definitely inlining __find_if(...,
| | random_access_iterator_tag), it's not an option, too big. The other one,
| | it's ok to inline, and it's already marked as such. Or you mean *the
| | latter* it's not inlined *always*, as it should (in order to also deal
| | with the problem with zeroing)? In that case, we could play a bit with
| | attribute always inline, perhaps. But, in general, I'm not sure to
| | really understand what you mean by "instantiate to zero"... In the
| | assembly of __ops::equal, before the eventual function call, is
| | memory/registers zeroed?!?
| 
| I'll try to be more clear :)
| 
| Consider the following code, with no inlining
| struct X { };
| void foo(X,X,X) { };
| 
| void call_foo()
| { foo(X(),X(),X()); }
| 
| Looking at the assembler output for this code, g++ appears to insist on
| making all classes at least 1 byte big, and also insists on
| instansiating this one byte to zero (I think thats whats happening
| anyway, I'll admit I'm not 100% sure). This is already a problem, for
| when we add random_access_iterator_tag() and such like, and a very minor
| problem (one more "assign zero"). But it's there.

Yes.  One of curiosities of GCC ABI is insisting on allocating registers
for values of empty classes and insisting on filling them with zero.
Nobody cares about those values but GCC thinks it must issue useless
loads and stores.  GCC needs to be taught that nobody really cares
about those values. And refrain from allocating registers for emmpty
classes (but then you go into ABI breaking territory).

start with EMPTY_CLASS_EXPR in cp/expr.c::cxx_expand_expr()

I would think that is a requirement for proper support for the kind of
refactorying you're doing. Ask a middle-end expert how to annotate
an expression nobody cares about.

- Gaby