Hi Sun,
I made a mistake in the previous patch. I only handled the case for
iload. I don't handle the istore. Could you please review the new
patch again:
Index: opt_htable.cxx
===================================================================
--- opt_htable.cxx (revision 3688)
+++ opt_htable.cxx (working copy)
@@ -2534,9 +2534,13 @@
CODEREP *retv;
OPERATOR oper = OPCODE_operator(opc);
+ // make sure the dtyp for constant base is Pointer_type
+ if (lbase != NULL && lbase->Kind() == CK_CONST
+ && lbase->Dtyp() != Pointer_type)
+ lbase->Set_dtyp_strictly(Pointer_type);
+ if (sbase != NULL && sbase->Kind() == CK_CONST
+ && sbase->Dtyp() != Pointer_type)
+ sbase->Set_dtyp_strictly(Pointer_type);
cr->Init_ivar(opc, dtyp, occ, dsctyp, lodty, lbase, sbase,
ofst, size, field_id);
2011/7/9 Sun Chan <sun.c...@gmail.com>:
> looks good
> Sun
>
> On Fri, Jul 8, 2011 at 8:11 PM, Jian-Xin Lai <laij...@gmail.com> wrote:
>> Hi,
>>
>> Can someone review the patch for bug #830. Thank you very much.
>>
>> For the ILOAD from address const 0xffffffffffff8001, the WHIRL IR is:
>> U8INTCONST -32767 (0xffffffffffff8001)
>> I4I4ILOAD 0 T<4,.predef_I4,4> T<53,anon_ptr.,8>
>>
>> when creating the CODEREP, after calling CANON_CR::Trim_to_16bits(),
>> the base of ILOAD will be trunk to 0 and -32767 will be stored to the
>> offset of the ILOAD. In current WOPT, the generated IR is:
>> U4INTCONST 0 (0x0)
>> I4I4ILOAD -32767 T<4,.predef_I4,4> T<53,anon_ptr.,8>
>>
>> We can find the type of the address is converted to U4. This is done
>> by CODEREP::Set_dtyp_const_val(MTYPE dt, INT64 v). When the constant
>> is in the range of U4, the dtyp will be set to U4. This will cause bad
>> code generation in CG. Since both the base and offset are 4 bytes, the
>> CG will generate ldc32 for the constant and finally generate the movl
>> instruction.
>>
>> Here is a patch to address this issue. The basic idea is to make sure
>> the dtyp for address is always Pointer_type.
>> Index: osprey/be/opt/opt_htable.cxx
>> ===================================================================
>> --- osprey/be/opt/opt_htable.cxx (revision 3648)
>> +++ osprey/be/opt/opt_htable.cxx (working copy)
>> @@ -2534,6 +2534,10 @@
>> CODEREP *retv;
>> OPERATOR oper = OPCODE_operator(opc);
>>
>> + // make sure the dtyp for address const is Pointer_type
>> + if (lbase->Kind() == CK_CONST && lbase->Dtyp() != Pointer_type)
>> + lbase->Set_dtyp_strictly(Pointer_type);
>> +
>> cr->Init_ivar(opc, dtyp, occ, dsctyp, lodty, lbase, sbase,
>> ofst, size, field_id);
>> // all IVAR codereps have a mu_node
>>
>>
>> --
>> Regards,
>> Lai Jian-Xin
>>
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Open64-devel mailing list
>> Open64-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/open64-devel
>>
>
--
Regards,
Lai Jian-Xin
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
