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
