Hanlding VECTOR_TYPE's in C++

[Daniel Berlin]

Since you were the last one to touch VECTOR_TYPE support in g++, going by 
the changelogs, , i figured i'd just ping you (and copy it to gcc in case 
you are too amazingly busy, since it's an easy job).

There are two places we still need to handle VECTOR_TYPES to make them work 
correctly in C++ programs (at least, to get things to compile that use them).
One is in cvt.c, in ocp_convert (I just copied the code from c-convert, 
basicllaly). This takes care of conversion to a VECTOR_TYPE.


The other is in typeck2.c, in digest_init. Just add VECTOR_TYPE to the or 
that handles scalar types, pointers, references (search on "Handle scalar 
types".). This takes care of initialization.

It's a total of three lines, and in combination with two other things 
i'll explain in a minute, i can successfully use VECTOR_TYPE based 
intrinsics in C++ programs.


The first other thing is where intrinsics get put.

Even though we really intend for them to be "extern "C"", because every 
intrinsics header i've ever seen, defines the intrinsics as macros like so:

#define _mm_set_ps1(x)  (__builtin_ia32_setps1(x))

,we can't extern them there.

We need to extern them by doing push_lang_context(lang_name_c)
before we call MD_INIT_BUILTINS in decl.c and  pop_lang_context() after
or, alternatively, do the same in the various intrinsic init routines.

Personally, i'd rather do the first way, because it's easier. I sincerely 
doubt anyone will write C++ based intrisics anytime soon, since they are 
basically just glorified asms.


The second issue is that because of how we init the intrinsics, we can't 
discern the void_type_node they use as an endlink when building the 
functions  from an ellipsis, 
because they never get passed to grokparms, and thus, it never gets 
transformed into a void_list_node.

I have a patch that just constructs a void_list_node, and uses that as 
the endlink instead. I assume this is the right thing to do? (It works 
for both C++ and C, I don't use any other GCC based languages). If so, 
i'll submit the patch.


Working on an SSA value numbering pass[1],
--Dan

[1] This was my weekend++  project for no reason other than to get off my 
ass and make gcc better (and learn more about ssa based optimizations) . It 
works on BB's, EBB's,  strongly connected 
components of the SSA graph, etc. It has a dominator based value numbering 
technique, and a unified hash table based technique, and an scc based 
value numbering technique, etc.

Basically a straight implementation of everything in L.T. Simpson's paper 
on value numbering.
It's getting there. About 70% done.

I skipped the tracing into/out of memory, and i didn't reimplement 
folding/simplification while we visit, since we already have routines to 
do this, which makes it cake to do later if we want.