[PATCH] rvalue reference implementation for C++0x

[Russell Yanofsky]

On Mon, 2007-03-19 at 09:21 -0400, Doug Gregor wrote:
> What if (a new) cp_build_reference_type keeps its own hash table of
> rvalue REFERENCE_TYPE references, but forwards to build_reference_type
> for lvalue references?

So, for rvalue references, cp_build_reference() will create its own
REFERENCE_TYPE nodes from scratch, bypassing build_reference_type() and
the TYPE_NEXT_REF_TO() logic. Since it needs to be able to look up the
rvalue reference type from the base type, but there is no extra field
for it, it will store the information in a global hash table instead. I
think this would work.

> I still think Jason's trick might just work... the front end only
> builds REFERNCE_TYPEs with mode==ptr_mode. So cp_build_reference_type
> would always make sure to build the lvalue REFERENCE_TYPE (mode ==
> ptr_mode) first, then put the rvalue REFERENCE_TYPE (also mode ==
> ptr_mode) later in the list. The common build_reference_type_for_mode
> will always find the first (lvalue) reference type, whereas
> cp_build_reference_type knows better and will also use the appropriate
> TYPE_LANG_FLAG bit.

Ok, I understand this better now. Using TYPE_LANG_FLAG bit is just an
optimization, and you can tell whether a REFERENCE_TYPE node is an
lvalue or rvalue type by looking at what order it appears in the
TYPE_NEXT_REF_TO list. This should also work.

So I guess there are four proposed solutions to the problem of rvalue
reference information encroaching into the middle end:

Solution 1: Generalize build_reference_type_* functions in the middle
end to be able to store a boolean flag and give types that set the flag
a unique place on the TYPE_NEXT_REF_TO chain. This is the simplest
approach, I just take the current patch and rename some functions and
macros so the rvalue reference stuff only appears in the C++ front end.

Solution 2: Create a new reference type node in the C++ front end that
stores l/r-value information and gets converted to REFERENCE_TYPE during
gimplification. This seems like the most elegant approach and is also
pretty simple, but it will result in a long patch with lots of
REFERENCE_TYPE -> CP_REFERENCE_TYPE and similar replacements.

Solution 3: Create rvalue reference types as REFERENCE_TYPE nodes, but
do not include them in the TYPE_NEXT_REF_TO lists like existing
references, instead map base types to rvalue reference types using a
global hash table.

Solution 4: Create rvalue reference types as REFERENCE_TYPE nodes and
include them in the TYPE_NEXT_REF_TO lists but in such a way that that
they are hidden from current TYPE_NEXT_REF_TO logic and won't interfere
with existing code.

Solutions 1 and 4 are the easiest to implement. Solutions 3 and 4 seem
kludgy to me in the way that they fiddle with middle end data structures
from the front end, but I think I'm the only one who feels that way. I'm
willing to do whatever, I'd just like somebody to tell me which
direction to go. Solution 4 seems like the path of least resistance at
this point, are there any objections to that?

-- 
-  Russell Yanofsky (PGP ID: 0x5FAA0216)
-  http://russ.yanofsky.org/
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20070319/227bca10/attachment.sig>