This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PR tree-opt/33614: ICE when optimising a "constant" vector constructor
"Andrew Pinski" <pinskia@gmail.com> writes:
> On 10/1/07, Richard Sandiford <rsandifo@nildram.co.uk> wrote:
>
>> Index: gcc/gimplify.c
>> ===================================================================
>> --- gcc/gimplify.c 2007-10-01 23:23:20.000000000 +0100
>> +++ gcc/gimplify.c 2007-10-01 23:24:13.000000000 +0100
>> @@ -3291,10 +3291,8 @@ gimplify_init_constructor (tree *expr_p,
>> break;
>> }
>>
>> - /* Don't reduce a TREE_CONSTANT vector ctor even if we can't
>> - make a VECTOR_CST. It won't do anything for us, and it'll
>> - prevent us from representing it as a single constant. */
>> - break;
>> + TREE_CONSTANT (ctor) = 0;
>> + TREE_INVARIANT (ctor) = 0;
>> }
>>
>> /* Vector types use CONSTRUCTOR all the way through gimple
>
> Doing this will loose some optimizations with vectors. The main
> reason why is because &a is not a CONSTANT_CLASS but still can be
> constant..
OK. How about keeping the break when none of the elements can throw?
And updating the comment so that it mentions this case too?
> Also can you look at the following testcase (with -O2 -msse):
> int t[4];
>
> __attribute__((vector_size(16))) int f(void)
> {
> __attribute__((vector_size(16))) int t1 = {(int)&t[0], (int)&t[1], (int)&t[2],
> (int)&t[3]};
> return t1;
> }
>
> And make sure we don't regress.
> Right now we get:
> f:
> pushl %ebp
> movdqa .LC0, %xmm0
> popl %ebp
> ret
> .LC0:
> .long t
> .long t+4
> .long t+8
> .long t+12
> Which is better than what we got in 4.0.2.
FWIW, that particular case still works.
Richard