Hi Fred,
Thank you for the comments. I made another code change in wgen_expr.cxx to
convert the I1/I2 to I4 for INTRINSIC_OP:
Index: ../osprey/wgen/wgen_expr.cxx
===================================================================
--- ../osprey/wgen/wgen_expr.cxx (revision 3506)
+++ ../osprey/wgen/wgen_expr.cxx (working copy)
@@ -9538,6 +9538,8 @@
case IRETURN_M8I1: ret_mtype = MTYPE_M8I1; break;
case IRETURN_M8I2: ret_mtype = MTYPE_M8I2; break;
case IRETURN_M8I4: ret_mtype = MTYPE_M8I4; break;
+ case IRETURN_I1:
+ case IRETURN_I2: ret_mtype = MTYPE_I4; break; // promote to
I4
default: ;
}
#endif
With this code change, the IR generated by wgen is:
V16I2V16I2LDID 0 <1,51,x> T<32,.predef_V16I8,16>
V16I2PARM 2 T<30,.predef_V16I2,16> # by_value
I4I4LDID 0 <2,2,i> T<4,.predef_I4,4>
I4PARM 2 T<4,.predef_I4,4> # by_value
I4INTRINSIC_OP 2 <920,PEXTRW> 0
I8I4LDID 0 <2,2,i> T<9,.predef_U8,8>
U8I8CVT
U8INTCONST 2 (0x2)
U8MPY
U8U8LDID 0 <2,1,baseAddr> T<53,anon_ptr.,8>
U8ADD
I2ISTORE 0 T<53,anon_ptr.,8> {line: 1/4}
It looks like this fix is much better than the previous one. Can I check it
in? Thank you very much.
2011/3/4 Fred Chow <frdc...@gmail.com>
> The I2INTRINSIC_OP can actually be I4INTRINSIC_OP without causing any
> other problem. In general, rtype should be a type corresponding to a
> register. Since there is no register of size I2, I'm not comfortable with
> rtype being I2.
>
> In the WHIRL document under INTRINSIC_OP, there is this comment:
>
> "The types I1, I2, U1, U2, M are only allowed in VH WHIRL."
>
> I would recommend the fix to just change WGEN to generate I4INTRINSIC_OP
> for the PEXTRW intrinsic.
>
> Fred
>
>
> On 03/02/2011 09:44 PM, Jian-Xin Lai wrote:
>
> WGEN never generates I2I2ILOAD. In this bug, I2I2ILOAD is generated by wopt
> when creating the CODEREP from WHIRL IR. This problem occurs when the result
> of an I2INTRINSIC_OP is on the rhs of an ISTORE. Here is a case:
> typedef long __m128i __attribute__ ((__vector_size__(16)));
> __m128i x;
> void foo(short *baseAddr, int i) {
> baseAddr[i] = __builtin_ia32_vec_ext_v8hi(x, i);
> }
>
> __builtin_ia32_vec_ext_v8hi returns I2. The IR generated by wgen is:
> V16I2V16I2LDID 0 <1,51,x> T<32,.predef_V16I8,16>
> V16I2PARM 2 T<30,.predef_V16I2,16> # by_value
> I4I4LDID 0 <2,5,i> T<4,.predef_I4,4>
> I4PARM 2 T<4,.predef_I4,4> # by_value
> I2INTRINSIC_OP 2 <920,PEXTRW> 0
> I8I4LDID 0 <2,5,i> T<9,.predef_U8,8>
> U8I8CVT
> U8INTCONST 2 (0x2)
> U8MPY
> U8U8LDID 0 <2,4,baseAddr> T<53,anon_ptr.,8>
> U8ADD
> I2ISTORE 0 T<53,anon_ptr.,8> {line: 1/5}
>
> In opt_htable.cxx, STMTREP::Enter_lhs(), line 4131:
> 4126 #ifdef TARG_SL
> 4127 if (dtyp == MTYPE_I2 && dsctyp == MTYPE_I2) {
> 4128 dtyp = MTYPE_I4;
> 4129 }
> 4130 #endif
> 4131 opc = OPCODE_make_op(opr == OPR_ISTORE ? OPR_ILOAD :
> OPR_ILDBITS, dtyp, dsctyp);
> 4132 base_ccr.Set_scale(base_ccr.Scale() + WN_offset(Wn()));
> 4133 base_ccr.Trim_to_16bits(WN_kid(Wn(), 1), htable);
>
> The dtyp comes from the rtype of rhs, which is I2. dsctyp comes from the
> desc type of ISTORE, which is also I2. Since I2I2ILOAD is an illegal opcode,
> an assertion will be triggered:
> ### Assertion failure at line 224 of
> /export/home/laijx/trunk/x86-debug/osprey/../../osprey/common/com/opcode.h:
> ### Compiler Error in file case.cxx during Global Optimization -- Create
> CODEMAP Representation phase:
> ### OPCODE_make_op: no opcode available: 52 3 3
>
> For the patch I posted to the list, it tries to resolve this assertion by
> changing the rtype(dtyp) to I4. Another possible solution is to allow
> I2I2ILOAD and change it to I4I2ILOAD before converted into CGIR. What's your
> suggestion? Thank you very much.
>
> 2011/2/28 Sun Chan <sun.c...@gmail.com>
>
>> I don't fully understand, if I2I2ILOAD is illegal, shouldn't the
>> generation of such be disabled? What SL did wrong was handling it.
>> Shouldn't the correct fix be in wgen or something like that? The way
>> it is, cg can see this code at O0 level, or if wopt is not ran
>> Sun
>>
>> On Mon, Feb 28, 2011 at 8:17 PM, Jian-Xin Lai <laij...@gmail.com> wrote:
>> > Hi,
>> >
>> > Can a gate keeper review the patch for I2I2ILOAD bug found in #695?
>> Thank
>> > you very much.
>> > https://bugs.open64.net/show_bug.cgi?id=695
>> >
>> > Based on previous discussion with Fred, I2I2ILOAD is illegal in WHIRL
>> IR.
>> > Basically, this patch is to remove SL's previous patch for I2I2ILOAD.
>> >
>> > --
>> > Regards,
>> > Lai Jian-Xin
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Free Software Download: Index, Search & Analyze Logs and other IT data
>> in
>> > Real-Time with Splunk. Collect, index and harness all the fast moving IT
>> > data
>> > generated by your applications, servers and devices whether physical,
>> > virtual
>> > or in the cloud. Deliver compliance at lower cost and gain new business
>> > insights. http://p.sf.net/sfu/splunk-dev2dev
>> > _______________________________________________
>> > Open64-devel mailing list
>> > Open64-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/open64-devel
>> >
>> >
>>
>
>
>
> --
> Regards,
> Lai Jian-Xin
>
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
>
>
> _______________________________________________
> Open64-devel mailing
> listOpen64-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/open64-devel
>
>
>
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> Open64-devel mailing list
> Open64-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/open64-devel
>
>
--
Regards,
Lai Jian-Xin
------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
