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