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 <mailto: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 <mailto: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 <mailto: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
<mailto: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 list
Open64-devel@lists.sourceforge.net
<mailto:Open64-devel@lists.sourceforge.net>
https://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
<mailto:Open64-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/open64-devel
--
Regards,
Lai Jian-Xin
