Re: [PATCH] Fix PR25500, pessimization on SSE code caused by count_type_elements (expr.c)

[Mark Mitchell <mark at codesourcery dot com>]

Paolo Bonzini wrote:
> 
>>>      case VECTOR_TYPE:
>>> -      return TYPE_VECTOR_SUBPARTS (type);
>>> +      return TYPE_MODE (type) == BLKmode ? TYPE_VECTOR_SUBPARTS
>>> (type) : 1;
>>>
>>>      case INTEGER_TYPE:
>>>      case REAL_TYPE:
>>>     
>> While I applaud the results of this patch, this doesn't really make
>> sense to me.  A vector has as many elements as it has, whether or not it
>> fits in a machine register.
> No, because if it fits in a machine register, we can copy N elements
> with a single instruction.  So it makes sense, in that case, to count
> the vector as a whole.  

What would you say about:

  struct S {
    char c;
    short s;
  };

That probably fits in a register on most machines, too.  I guess the
answer is that such structures are BLKmode, not SImode, but that if they
*were* SImode (which, conceivably, they could be in future), you'd
consider them 1-element structures?

> For example, we should not count a V16QImode
> vector with 15 zeros and 1 non-zero element as "mostly zero".

That makes sense, if we're using a V16QImode instruction to initialize
it.  However, if it's a structure sitting in memory, then it is mostly
zero.  That's part of what I find confusing.  Mostly-zeroness is used
when deciding how to zero a structure, under the assumption that it's
living in memory, in which case the modes of the fields doesn't seem
useful to me.  Maybe there are other places where this predicate is used
too, but I don't understand how these cases are being distinguished.

>>   That's a philosophical concern, but more
>> practically, won't gimplify_init_constructor break?
>>   
> No, because it does not invoke count_type_elements for VECTOR_TYPEs.

OK.

To be clear, I'm not rejecting your patch; I'm just not understanding
it. :-)

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713