[RFC/RFT] Tree-level lowering of generic vectors, part 2

[Paolo Bonzini]

>>+/* Build a constant of type TYPE, made of VALUE's bits replicated
>>+   to fit TYPE's size.  */
>>+static tree
>>+build_replicated_const (tree type, tree inner_type, HOST_WIDE_INT value)
 >
> Description should be "... to fit INNER_TYPE's size"?

No, "made of VALUE's bits, replicated to fit TYPE's size every TYPE_SIZE 
(INNER_TYPE) bits."

>>+  HOST_WIDE_INT max;
>>+  low_bits = build_replicated_const (word_type, inner_type, max >> 1);
> 
> Max needs to be unsigned for this to work as you expect.

Actually, it works because build_replicated_const is only called when 
four vector items fit in a target word.  The same holds for using a left 
shift there.  But I adjusted both of them for the sake of clarity.

>>+  op = optab_for_tree_code (code == NEGATE_EXPR ? MINUS_EXPR : code, type);
> 
> Using minus instead of negate gets the wrong answer for floating point.

This is done unconditionally by optabs for MODE_FLOAT (not for 
MODE_VECTOR_FLOAT because control has already been passed to 
expand_vector_unop):

   if (unoptab->code == NEG)
     {
       rtx temp;
       temp = expand_binop (mode,
                        unoptab == negv_optab ? subv_optab : sub_optab,
                        CONST0_RTX (mode), op0, target,
                        unsignedp, OPTAB_LIB_WIDEN);
       if (temp)
         return temp;
     }

> We do have negv4sf2, on i386 at least; others can be updated, or we can
> implement the note in i386.md:
> 
>   ;; ??? Should probably be done by generic code instead.
> 
> since we generate "x ^ { 0x80000000 x width }".  And note that the 
> constant there is derivable from real_format_for_mode[mode].signbit.

I will do it as a follow-up.

>>+	  /* When not optimizing, only lower complex arithmetic.  This is so
>>+	     that the loop optimizers do not waste time on lowered vectors...
> 
> You mean silly things like moving invariant code out of loops and the like?

I thought that these are done after vectorization, immediately after 
which I'd put the tree lowering pass; instead, I see on lno-branch that 
PRE and loop-invariant motion are both done before other loop opts such 
as vectorizing.  I don't know how easily this can be changed, and with 
what results (Dorit?).

I was worried about the vectorizer vectorizing uselessly something that 
was converted to scalars (it could do this even if vector modes are not 
available, if the loops contains logical operations).

> And what, exactly, would be wrong with rerunning the pass iff the loop
> code did decide to generate vector operations?

Nothing.

I committed part1 after running the testsuite.  The check-in is at
http://gcc.gnu.org/ml/gcc-cvs/2004-07/msg01075.html

Can I commit the gimplify_buildN changes as well?

Here is part2.  I've moved the code to pick the mode into layout_type.

Paolo
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: tree-vec-lowering.patch
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20040721/76f75cdf/attachment.ksh>