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, Andrew Pinski <pinskia@gmail.com> wrote:
>> 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;
>> }
>
> Or the following testcase for PPC:
> int t[4];
> __attribute__((vector_size(16))) int g;
>
> void f(void)
> {
> __attribute__((vector_size(16))) int t1 = {(int)&t[0], (int)&t[1], (int)&t[2],
> (int)&t[3]};
> g = t1;
> }
>
> ---------- CUT ---------------------
> Right now we get:
> lis 9,.LANCHOR0@ha
> lis 11,g@ha
> la 9,.LANCHOR0@l(9)
> la 11,g@l(11)
> lvx 0,0,9
> stvx 0,0,11
> blr
>
> But with your patch, we will not force the constant vector into
> constant memory so we get at least one load hit store hazzard (on the
> Cell) as we will be storing out to the stack the vector and then
> loading it back up.
OK, you've convinced me that this is deeper than I first realised.
I was misled by the gimplify.c comment, which implied that it was
only dealing with trapping cases.
It'd probably best if I unassign myself from this one. It's really
33616 that I'm trying to fix.
Richard