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
gvn_align_bugfixes.p
Description: gvn_align_bugfixes.p
------------------------------------------------------------------------------ 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
