I said, send me the entire expr (you just sent const and cvtl)
I want to know why const became I8 where the input is I4
On Tue, Nov 29, 2011 at 10:49 AM, Gang Yu <yugang...@gmail.com> wrote:
> 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
>>
>>
> On Tue, Nov 29, 2011 at 10:40 AM, Sun Chan <sun.c...@gmail.com> wrote:
>
>> we can go on forever if you only want to give me minimum info. Pls send
>> me the entire expr
>> Sun
>>
>
> Sorry, I have sent the function code, the input, the unexpected and
> expected output. Due to my limitation, I am not sure what you exactly
> want? please
>
> Regards
> Gang
>
>
>
>>
>>
> On Tue, Nov 29, 2011 at 10:16 AM, Gang Yu <yugang...@gmail.com> wrote:
>>
>>> Before the change, the input expression is wrongly codemapped to
>>>
>>> >LDC I8 -2147483649 <u=1 cr17> flags:0x0 b=-1
>>>
>>> it should be rightly mapped to:
>>>
>>> > LDC I8 -2147483649 <u=1 cr17> flags:0x0 b=-1
>>> >U4I4CVT <u=1 cr18> isop_flags:0x0 flags:0x0 b=-1
>>>
>>> Regards
>>> Gang
>>>
>>>
>>> On Mon, Nov 28, 2011 at 8:22 PM, Sun Chan <sun.c...@gmail.com> wrote:
>>>
>>>> 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:
>>>>
>>>>>
>>>>>
>>>>>> 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
