The rest of the patch looks fine to me.
2011/4/20 Sun Chan <sun.c...@gmail.com>
> I am ok with the wopt fix. One minor comment, your change does not
> need to be enclosed inside x86_64
> Sun
>
> On Wed, Apr 20, 2011 at 6:34 AM, Mathew, Pallavi <pallavi.mat...@amd.com>
> wrote:
> > Hi,
> >
> > Can a gatekeeper please review the attached patch that:
> >
> > 1. Fixes a bug in GVN which was not able to differentiate scalar and
> >
> > vector constant. For example, 2.1 and <2.1, 2.1> would get the same
> >
> > value number and this bug could cause run time as well compile-time
> > problems.
> >
> > This fix updates:
> >
> > osprey/be/opt/opt_vnfre.cxx
> >
> > osprey/be/opt/opt_etable.cxx
> >
> > osprey/be/opt/opt_etable.h
> >
> > osprey/be/opt/opt_vn.cxx
> >
> > osprey/be/opt/opt_vn_expr.h
> >
> > osprey/be/opt/opt_vn_expr.cxx
> >
> > osprey/be/opt/opt_vn_expr_taxonomy.h
> >
> >
> >
> > 2. Fixes an alignment bug. The problem can be explained by the following
> f90
> > snippet.
> >
> > Statemnt 22 (which is a loop with 3 iterations) is vectorized. Neither
> > input%field2%arr nor
> >
> > input%field1%arr is aligned properly. However, compiler generates aligned
> > load instructions for
> >
> > them causing segmentation fault at runtime.
> >
> >
> >
> > 1 module foobar
> >
> > 2 implicit none
> >
> > 3
> >
> > 4 type t1
> >
> > 5 integer :: pad1
> >
> > 6 integer :: pad2
> >
> > 7 integer :: pad3
> >
> > 8 real*8, dimension(3) :: arr
> >
> > 9 end type t1;
> >
> > 10
> >
> > 11 type t2
> >
> > 12 type(t1) :: field1
> >
> > 13 type(t1) :: field2
> >
> > 14 end type t2;
> >
> > 15
> >
> > 16 contains
> >
> > 17
> >
> > 18 subroutine foo(input)
> >
> > 19 type(t2) :: input
> >
> > 20 real*8, dimension(3) :: arr2;
> >
> > 21
> >
> > 22 arr2 = input%field2%arr - input%field1%arr
> >
> > 23 call bar (arr2);
> >
> > 24 end subroutine foo
> >
> > 25
> >
> > 26 end module foobar
> >
> > This fix updates:
> >
> > osprey/be/cg/whirl2ops.cxx
> >
> >
> >
> > 3. Fixes a problem illustrated with the snippet shown below built with
> -O3.
> >
> > <mydata> is accessed using aligned SIMD instruction no matter this
> snippet
> >
> > is built with -m32 or -m64. With -m32, the SP is not guaranteed to land
> at
> >
> > 16-byte boundary, therefore we are not able to *statically* allocate a
> local
> >
> > var at 16-byte boundary.
> >
> >
> >
> > ------------------------------
> >
> > void foo (void) {
> >
> > int i, mydata[4];
> >
> > for (i= 0; i < 4; i++)
> >
> > mydata[i] = 1;
> >
> >
> >
> > extern void bar (int*);
> >
> > bar (&mydata);
> >
> > }
> >
> > -------------------------------
> >
> >
> >
> > The root cause is that with -m32, stack frame is 8-byte aligned, and
> >
> > therefore local variables cannot be statically aligned at a boundary more
> >
> > stringent than 8-byte alingment (unless one use alloca() to allocate
> >
> > space for local var). Using aligned SSE instructions to load/store
> >
> > local arrays will incur segmentation fault.
> >
> > There are two problems fixed by the change:
> >
> > i) Register allocation doesn't respect a variable's alignment when
> >
> > it spills/restores to/from its home location.
> >
> > ii) local variables should not have more stringent alignment than stack
> > frame.
> >
> > This fix updates:
> >
> > osprey/be/cg/whirl2ops.cxx
> >
> > osprey/be/cg/cg_spill.cxx
> >
> > osprey/be/com/data_layout.cxx
> >
> >
> >
> > Thanks.
> >
> > Pallavi
> >
> >
> ------------------------------------------------------------------------------
> > Benefiting from Server Virtualization: Beyond Initial Workload
> > Consolidation -- Increasing the use of server virtualization is a top
> > priority.Virtualization can reduce costs, simplify management, and
> improve
> > application availability and disaster protection. Learn more about
> boosting
> > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> > _______________________________________________
> > Open64-devel mailing list
> > Open64-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/open64-devel
> >
> >
>
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________
> Open64-devel mailing list
> Open64-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/open64-devel
>
--
Regards,
Lai Jian-Xin
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
