This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]