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
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
https://lists.sourceforge.net/lists/listinfo/open64-devel
