without your change, what is the output of this function for the same input
expr?
Sun
On Mon, Nov 28, 2011 at 10:50 AM, Gang Yu <yugang...@gmail.com> wrote:
> opt_htable.cxx
> 2244BOOL
> 2245CODEMAP::Canon_cvt(WN *wn,
> 2246 OPT_STAB *opt_stab,
> 2247 STMTREP *stmt,
> 2248 CANON_CR *ccr,
> 2249 CODEREP *cr,
> 2250 COPYPROP *copyprop)
> 2251{
> 2252 const OPCODE op = WN_opcode(wn);
> 2253 WN *kid = WN_kid(wn, 0);
> 2254 BOOL propagated = Add_expr(kid, opt_stab, stmt, ccr, copyprop);
> 2255#if defined(TARG_NVISA)
> 2256 if (ccr->Tree() == NULL) {
> 2257 // There is only a constant value in ccr
> 2258 return propagated;
> 2259 }
> 2260#endif
> 2261
> 2262#if defined (TARG_MIPS) && !defined (TARG_SL)
> 2263 // U8I4CVT and I8I4CVT are nops so return kid, MIPS III and above
> 2264 // since U8I4CVT is required to preserve the type of its type for
> 2265 // Fix_var_type at emitter time, we do not delete U8I4CVT #329096
> 2266 if (Is_Target_ISA_M3Plus() && (op == OPC_I8I4CVT || op ==
> OPC_U8I4CVT))
> 2267 return propagated;
> 2268#elif defined(TARG_X8664)
> 2269 if (! Is_Target_32bit() && op == OPC_U8U4CVT)
> 2270 return propagated;
> 2271#endif
> 2272 if ((Get_mtype_class(OPCODE_rtype(op)) &
> 2273 Get_mtype_class(OPCODE_desc(op))) != 0 &&
> 2274 MTYPE_size_min(OPCODE_rtype(op)) ==
> MTYPE_size_min(OPCODE_desc(op)) &&
> 2275 // bug912 open64.net. Do not delete U4I4CVT if his kid is a
> constant
> 2276 (!(OPCODE_rtype(op) == MTYPE_U4 &&
> 2277 OPCODE_desc(op) == MTYPE_I4 &&
> 2278 ccr->Tree() == NULL)))
> 2279 return propagated;
> 2280
> 2281 if ( WOPT_Enable_Cvt_Folding &&
> 2282#if defined(TARG_X8664) || defined(TARG_NVISA) || defined (TARG_SL) //
> bug 5851
> 2283 ! Is_Target_32bit() &&
> 2284#endif
> 2285 (op == OPC_I8U4CVT || op == OPC_U8U4CVT) &&
> 2286 WN_operator(kid) == OPR_LSHR ) {
> 2287 WN *bits = WN_kid1(kid);
> 2288 if ( WN_operator(bits) == OPR_INTCONST ) {
> 2289 INT bits_cnt = WN_const_val(bits);
> 2290 INT result_size = Actual_data_size(kid);
> 2291 if ( ( result_size <= MTYPE_size_min(MTYPE_I4) ) &&
> 2292 ( ( bits_cnt & 0x1F ) != 0 ) )
> 2293 {
> 2294 return propagated;
> 2295 }
> 2296 }
> 2297 }
> 2298
> 2299 CODEREP *retv;
> 2300 CODEREP *expr;
> 2301#if defined(TARG_X8664) || defined(TARG_NVISA)
> 2302 if (!Is_Target_32bit() && ccr->Tree() != NULL &&
> Allow_wrap_around_opt) {
> 2303 if (ccr->Tree()->Kind() == CK_OP && ccr->Tree()->Op() ==
> OPC_I8I4CVT &&
> 2304 op == OPC_I4I8CVT) { // bug 10707
> 2305 retv = ccr->Tree()->Opnd(0);
> 2306 ccr->Set_tree(retv);
> 2307 }
> 2308 else {
> 2309 cr->Set_opnd(0, ccr->Tree());
> 2310 retv = Hash_Op(cr);
> 2311 ccr->Set_tree(retv); // move the CVT to the operand
> 2312 }
> 2313 }
> 2314 else {
> 2315#endif
> 2316 expr = ccr->Convert2cr(WN_kid0(wn), this, propagated);
> 2317 cr->Set_opnd(0, expr);
> 2318 retv = Hash_Op(cr);
> 2319 ccr->Set_tree(retv);
> 2320 ccr->Set_scale(0);
> 2321#if defined(TARG_X8664) || defined(TARG_NVISA)
> 2322 }
> 2323#endif
> 2324 return propagated;
> 2325}
>
> With this fix, controls goes to 2316,
> expr is
> >LDC I8 -2147483649 <u=1 cr17> flags:0x0 b=-1
> retv is
> > LDC I8 -2147483649 <u=1 cr17> flags:0x0 b=-1
> >U4I4CVT <u=1 cr18> isop_flags:0x0 flags:0x0 b=-1
> the input is still:
> I4INTCONST 1 (0x1)
> I4I4LDID 0 <st 20> T<4,.predef_I4,4>
> I4SHL
> I4INTCONST -1 (0xffffffffffffffff)
> I4ADD
> U4I4CVT
>
>
> Regards
> Gang
>
>
> On Mon, Nov 28, 2011 at 10:40 AM, Sun Chan <sun.c...@gmail.com> wrote:
>
>> Sorry, pls send the corresponding function so I get a bigger picture of
>> what the deal is. It will be good to give me the expression tree before and
>> after this function call
>> Sun
>>
>> On Mon, Nov 28, 2011 at 10:30 AM, Gang Yu <yugang...@gmail.com> wrote:
>>
>>> Inspired by your comments, I get a more reasonable fix.
>>>
>>> osprey/be/opt/opt_htable.cxx -- 1fc05d0..0b7a14a 100644
>>> --- a/osprey/be/opt/opt_htable.cxx
>>> +++ b/osprey/be/opt/opt_htable.cxx
>>> @@ -2271,7 +2271,11 @@ CODEMAP::Canon_cvt(WN *wn,
>>> #endif
>>> if ((Get_mtype_class(OPCODE_rtype(op)) &
>>> Get_mtype_class(OPCODE_desc(op))) != 0 &&
>>> - MTYPE_size_min(OPCODE_rtype(op)) ==
>>> MTYPE_size_min(OPCODE_desc(op)))
>>> + MTYPE_size_min(OPCODE_rtype(op)) ==
>>> MTYPE_size_min(OPCODE_desc(op)) &&
>>> + // bug912 open64.net. Do not delete U4I4CVT if his kid is a
>>> constant
>>> + (!(OPCODE_rtype(op) == MTYPE_U4 &&
>>> + OPCODE_desc(op) == MTYPE_I4 &&
>>> + ccr->Tree() == NULL)))
>>> return propagated;
>>> if ( WOPT_Enable_Cvt_Folding &&
>>> This new patch does not lost the chances to U4I4CVT optimisation, while
>>> it makes the case of U4I4CVT const right.
>>>
>>> Thanks a lot.
>>>
>>> Regards
>>> Gang
>>>
>>>
>>> On Mon, Nov 28, 2011 at 6:23 AM, Sun Chan <sun.c...@gmail.com> wrote:
>>>
>>>> so the const is of the right type to start out with. I'm not sure
>>>> htable is the right place to fix this (you could well be inhibiting
>>>> perfectly good optimization with your change).
>>>> I will need much more detail dump (e.g.when BAND first appear, before
>>>> and after) to know more about that.
>>>> Sun
>>>>
>>>> On Sun, Nov 27, 2011 at 9:48 PM, Gang Yu <yugang...@gmail.com> wrote:
>>>>
>>>>>
>>>>> On 11/27/2011 03:02 PM, Sun Chan wrote:
>>>>>
>>>>> you only showed the output, can you show input to htable?
>>>>> Sun
>>>>>
>>>>> Sun, Input of this expression:
>>>>>
>>>>> I4INTCONST 1 (0x1)
>>>>> I4I4LDID 0 <st 20> T<4,.predef_I4,4>
>>>>> I4SHL
>>>>> I4INTCONST -1 (0xffffffffffffffff)
>>>>> I4ADD
>>>>> U4I4CVT
>>>>>
>>>>> st 20 is var i ( copyproped to 31)
>>>>>
>>>>> regards
>>>>> Gang
>>>>>
>>>>> On Sun, Nov 27, 2011 at 11:24 AM, Gang Yu <yugang...@gmail.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Could a gatekeeper please help review the fix for bug912?
>>>>>> http://bugs.open64.net/show_bug.cgi?id=912
>>>>>>
>>>>>> The cut down bug case:
>>>>>>
>>>>>> struct go7007 {
>>>>>> int sensor_framerate;
>>>>>> int fps_scale;
>>>>>> };
>>>>>> int vti_bitlen(struct go7007 *go)
>>>>>> {
>>>>>> unsigned int i, max_time_incr = go->sensor_framerate / go->fps_scale;
>>>>>> for (i = 31; (max_time_incr & ((1 << i) - 1)) == max_time_incr; --i);
>>>>>> return i + 1;
>>>>>> }
>>>>>> ### Assertion failure at line 2109 of
>>>>>> /fc/proj/ctires/open64/o64guru/src/Sat/trunk/osprey/be/cg/cgemit.cxx:
>>>>>> ### Compiler Error in file bug912-cutdown.c during Assembly phase:
>>>>>> ### literal for operand 1 is not in range
>>>>>> Analysis:
>>>>>> WHIRL dump snippet after WOPT:
>>>>>> ......
>>>>>> U4STID 50 <1,8,.preg_U4> T<8,.predef_U4,4> # max_time_incr {line:
>>>>>> 1/8}
>>>>>> U4U4LDID 50 <1,8,.preg_U4> T<8,.predef_U4,4> # max_time_incr
>>>>>> U4U4LDID 50 <1,8,.preg_U4> T<8,.predef_U4,4> # max_time_incr
>>>>>> I8INTCONST -2147483649 (0xffffffff7fffffff)
>>>>>> U4BAND
>>>>>> I4U4EQ
>>>>>> FALSEBR L2562 {line: 0/0}
>>>>>>
>>>>>> This is already wrong, U4BAND should not accept I8INTCONST kids.
>>>>>>
>>>>>> ((1 << 31) - 1) in such context should be codemapped to U4INTCONST
>>>>>> 2147483647 (0x7fffffff)
>>>>>>
>>>>>> Suggested patch:
>>>>>>
>>>>>> --- a/osprey/be/opt/opt_htable.cxx
>>>>>> +++ b/osprey/be/opt/opt_htable.cxx
>>>>>> @@ -3679,7 +3679,10 @@ CODEMAP::Add_expr(WN *wn, OPT_STAB *opt_stab,
>>>>>> STMTREP *stmt, CANON_CR *ccr,
>>>>>> if ((MTYPE_type_class(OPCODE_rtype(op)) &
>>>>>> MTYPE_CLASS_INTEGER) != 0
>>>>>> #ifdef TARG_X8664 // bug 7733
>>>>>> && ! MTYPE_is_vector(OPCODE_rtype(op))
>>>>>> - && ! MTYPE_is_vector(OPCODE_desc(op))
>>>>>> + && ! MTYPE_is_vector(OPCODE_desc(op))
>>>>>> + // bug912 open64.net. do not Canonicalize U4I4CVT
>>>>>> + && ! (OPCODE_rtype(op) == MTYPE_U4 &&
>>>>>> + OPCODE_desc(op) == MTYPE_I4)
>>>>>> #endif
>>>>>> )
>>>>>> return Canon_cvt(wn, opt_stab, stmt, ccr, cr, copyprop);
>>>>>> Could a gatekeeper please help review ? Thanks
>>>>>>
>>>>>> Regards
>>>>>> Gang
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> All the data continuously generated in your IT infrastructure
>>>>>> contains a definitive record of customers, application performance,
>>>>>> security threats, fraudulent activity, and more. Splunk takes this
>>>>>> data and makes sense of it. IT sense. And common sense.
>>>>>> http://p.sf.net/sfu/splunk-novd2d
>>>>>> _______________________________________________
>>>>>> Open64-devel mailing list
>>>>>> Open64-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/open64-devel
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
