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
