That is fine as long as you gone through the testing. We did that at
SL, just not enough test cases for general purpose hence the ifdef
Sun
On Thu, Jan 13, 2011 at 1:02 PM, Jian-Xin Lai <laij...@gmail.com> wrote:
> Hi Sun,
> Could you please review another patch for the bug found in fixing bug 695:
> ### Assertion failure at line 2355 of
> /export/home/laijx/trunk/x86-debug/osprey/../../osprey/be/opt/opt_alias_analysis.cxx:
> ### Compiler Error in file /home/laijx/vc/tests/deinterleave.cpp during
> Global Optimization -- Create MU and CHI list phase:
> ### Allocate_mu_chi_and_virtual_var: Alias class 49 for PARM not consistent
> (0).
>
> There is an assertion when handle the LDDQU intrinsic. The reason is in a
> previous patch for WN_Parm_Deference, we only enable it for x86 in
> opt_alias_analysis, not in opt_alias_class, which cause the alias class does
> not match (49 in alias analysis vs 0 in alias classification) between the
> two component. The patch is to remove the two "#ifdef TARG_SL" from the
> source code.
>
> Index: osprey/be/opt/opt_alias_class.cxx
> ===================================================================
> --- osprey/be/opt/opt_alias_class.cxx (revision 3454)
> +++ osprey/be/opt/opt_alias_class.cxx (working copy)
> @@ -1117,9 +1117,7 @@
> // PARM, since we want our return value to describe all the
> // information available to the callee.
> else if (OPCODE_is_load(opc) ||
> -#if defined (TARG_SL)
> (opr == OPR_PARM && WN_Parm_Dereference(expr)) ||
> -#endif
> Is_fortran_reference_parm(expr)) {
> FmtAssert(OPERATOR_is_scalar_iload (opr) ||
> opr == OPR_MLOAD ||
> @@ -2182,9 +2180,7 @@
> }
> else if (OPCODE_is_load(opc) ||
> OPCODE_is_store(opc) ||
> -#if defined (TARG_SL)
> (opr==OPR_PARM && WN_Parm_Dereference(wn)) ||
> -#endif
> Is_fortran_reference_parm(wn) ||
> ((opr == OPR_LDA || opr == OPR_LDMA) &&
> Is_LDA_of_variable(wn))) {
>
>
> 2011/1/12 Sun Chan <sun.c...@gmail.com>
>>
>> looks good. The evil of "statics"
>> I much prefer this to be a class, but, legacy and all kind of changes. Too
>> bad.
>> Sun
>>
>> On Wed, Jan 12, 2011 at 3:03 PM, Jian-Xin Lai <laij...@gmail.com> wrote:
>> > Hi,
>> >
>> > Could a gate keeper review the patch to bug 695? Thank you very much.
>> >
>> > This bug is caused by the inconsistent of Promoted_Mtypes[] defined in
>> > both
>> > vho_lower.cxx and wn_lower.cxx. When the SIMD types was added to the
>> > array,
>> > only the definition in wn_lower.cxx is updated. In VHO lower phase, the
>> > old
>> > one is still used. The patch removes the definition in vho_lower.cxx and
>> > change the definition in wn_lower.cxx from static to global. So that we
>> > only
>> > need to maintain one definition.
>> >
>> > Index: com/wn_lower.cxx
>> > ===================================================================
>> > --- com/wn_lower.cxx (revision 3454)
>> > +++ com/wn_lower.cxx (working copy)
>> > @@ -371,7 +371,7 @@
>> >
>> > static const char * MSTORE_ACTIONS_name(MSTORE_ACTIONS);
>> >
>> > -static TYPE_ID Promoted_Mtype[MTYPE_LAST + 1] = {
>> > +TYPE_ID Promoted_Mtype[MTYPE_LAST + 1] = {
>> > MTYPE_UNKNOWN, /* MTYPE_UNKNOWN */
>> > MTYPE_UNKNOWN, /* MTYPE_B */
>> > MTYPE_I4, /* MTYPE_I1 */
>> > Index: vho/vho_lower.cxx
>> > ===================================================================
>> > --- vho/vho_lower.cxx (revision 3454)
>> > +++ vho/vho_lower.cxx (working copy)
>> > @@ -173,37 +173,10 @@
>> >
>> > /* Table used to promote integers less than 4 bytes into their
>> > * 4 byte counterparts in order to get the right type for
>> > OPCODE_make_op
>> > + * See definitions in wn_lower.cxx
>> > */
>> > +extern TYPE_ID Promoted_Mtype [MTYPE_LAST + 1];
>> >
>> > -TYPE_ID Promoted_Mtype [MTYPE_LAST + 1] = {
>> > - MTYPE_UNKNOWN, /* MTYPE_UNKNOWN */
>> > - MTYPE_UNKNOWN, /* MTYPE_B */
>> > - MTYPE_I4, /* MTYPE_I1 */
>> > - MTYPE_I4, /* MTYPE_I2 */
>> > - MTYPE_I4, /* MTYPE_I4 */
>> > - MTYPE_I8, /* MTYPE_I8 */
>> > - MTYPE_U4, /* MTYPE_U1 */
>> > - MTYPE_U4, /* MTYPE_U2 */
>> > - MTYPE_U4, /* MTYPE_U4 */
>> > - MTYPE_U8, /* MTYPE_U8 */
>> > - MTYPE_F4, /* MTYPE_F4 */
>> > - MTYPE_F8, /* MTYPE_F8 */
>> > - MTYPE_F10, /* MTYPE_F10 */
>> > - MTYPE_UNKNOWN, /* MTYPE_F16 */
>> > - MTYPE_UNKNOWN, /* MTYPE_STR */
>> > - MTYPE_FQ, /* MTYPE_FQ */
>> > - MTYPE_M, /* MTYPE_M */
>> > - MTYPE_C4, /* MTYPE_C4 */
>> > - MTYPE_C8, /* MTYPE_C8 */
>> > - MTYPE_CQ, /* MTYPE_CQ */
>> > - MTYPE_V, /* MTYPE_V */
>> > - MTYPE_UNKNOWN, /* MTYPE_BS */
>> > - MTYPE_UNKNOWN, /* MTYPE_A4 */
>> > - MTYPE_UNKNOWN, /* MTYPE_A8 */
>> > - MTYPE_C10, /* MTYPE_C10 */
>> > - MTYPE_C16, /* MTYPE_C16 */
>> > -};
>> > -
>> > #ifdef VHO_DEBUG
>> > static BOOL VHO_Switch_Debug = TRUE;
>> > static BOOL VHO_Struct_Debug = TRUE;
>> >
>> > BTW, there are several bugs exposed by compiling the case of 695. I'm
>> > still
>> > working on those and will submit more patch for that library.
>> >
>> > --
>> > Regards,
>> > Lai Jian-Xin
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Protect Your Site and Customers from Malware Attacks
>> > Learn about various malware tactics and how to avoid them. Understand
>> > malware threats, the impact they can have on your business, and how you
>> > can protect your company and customers by using code signing.
>> > http://p.sf.net/sfu/oracle-sfdevnl
>> > _______________________________________________
>> > Open64-devel mailing list
>> > Open64-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/open64-devel
>> >
>> >
>
>
>
> --
> Regards,
> Lai Jian-Xin
>
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
