sorry, I am not used to discussing whirl issues in the abstract. would you care to give a program statement so I can see exactly what you ultimately want to do? say, x = y-z; or something like that? What I don't see here is your final result, you only showed the rhs of the expr. Sun
On Thu, Oct 14, 2010 at 4:33 AM, xyzzy1959 <[email protected]> wrote: > Hi, > > I have some simple questions I hope somebody can answer. > > Given > > WN* op1; > WN* op2; > > With op1 being > > U8U8LDID > U4U8CVT > > and op2 being > > I4I4LDID > INEG > > I wrote > > op2 = WN_Type_Conversion(op2, MTYPE_U4); > op1 = WN_Add(MTYPE_U4, op2, op1); > > I was surprised to see the WHIRL as > > U8U8LDID > U4U8CVT > I4I4LDID > I4SUB > > I really wanted an unsigned since I want to zero-extend that to an MTYPE_U8 > with a U8U4CVT, but with the I4SUB, my code trips into generating an U8I4CVT > which sign-extends, not zero-extends. > > I even tried a WN_Type_Conversion after the WN_Add but that didn't do much. > > Tracking it down, I have two questions/concerns: > > - WN_Int_Type_Conversion (called from WN_Type_Conversion) pretty much treats > I4s > and U4s as identical. So when I called WN_Type_Conversion on 'op2', it just > returned the INEG node. > > - WN_Add eventually calls simp_add_sub() inside wn_simp_code.h. It > wants to fold > the INEG away by turning the ADD into a SUB. No problem on the > surface, but I found > code near the top of simp_add_sub() > > if (issub) { > subop = opc; > addop = OPC_FROM_OPR(OPR_ADD,ty); > } else { > addop = opc; > subop = OPC_FROM_OPR(OPR_SUB,ty); > #ifdef TARG_X8664 // bug 11400: if any operand is signed type, make SUB signed > if (MTYPE_signed(SIMPNODE_rtype(k0)) || MTYPE_signed(SIMPNODE_rtype(k1))) > subop = OPC_FROM_OPR(OPR_SUB, Mtype_TransferSign(MTYPE_I4, ty)); > #endif > > so later when the code simplifies the ADD/NEG into a SUB, you get a MTYPE_I4, > not the requested MTYPE_U4. (I'm on a X8664 target of course) > > } else if (SIMPNODE_operator(k1)==OPR_NEG) { > SHOW_RULE(" x + (-y) "); > r = SIMPNODE_SimpCreateExp2(subop,k0,SIMPNODE_kid0(k1)); > SIMP_DELETE(k1); > > > So finally to my questions: > > Seems I cannot trust WN_Add to honor my MTYPE_U4 requests for X8664 targets? > Why just for X8664? If it is a matter of algebraic correctness, why not all > targets? If it is some assumption on the eventual generated code, seems > risky. > > WN_Int_Type_Conversion doesn't seem to help me out of this situation with its > I4/U4 equality. > > I noticed what wgen avoids WN_Type_Conversion and calls WN_Cvt itself when > converts are needed. Is WN_Type_Conversion only for certain situations and > not for general use? > > Thanks! > > John > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb > _______________________________________________ > Open64-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/open64-devel > ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb _______________________________________________ Open64-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/open64-devel
