Last mail showed current trunk output, after patched:
---- BB3 (RPO 3) (LOGIF) (e) LINE 0 (rid_id:0) (flag:207)
Preds:2
Succs:9 4
Fallthrough: 4
Next : BB4
Prev : BB2
Idom : BB2
Ipdom : BB9
dom_dfs_id(2), dom_dfs_last(9)
pdom_dfs_id(2), pdom_dfs_last(4)
9 4
Pdom :2
Dom Frontier :4 {}
RCFG Dom Frontier :4 {}
> LDID U4 U4 sym3v3 0 ty=802 <u=4 cr12> flags:0x0 b=-1 #max_time_incr
> LDID U4 U4 sym3v3 0 ty=802 <u=4 cr12> flags:0x0 b=-1 #max_time_incr
> LDC U4 2147483647 <u=1 cr19> flags:0x0 b=-1
> U4BAND <u=1 cr20> isop_flags:0x0 flags:0x0 b=-1
> I4U4EQ <u=1 cr21> isop_flags:0x0 flags:0x0 b=-1
>OPR_FALSEBR 1538 b=-1 flags:0x2 pj2 Sid-1
I8CONST does not appear.
Regards
Gang
On Tue, Nov 29, 2011 at 12:38 PM, Sun Chan <sun.c...@gmail.com> wrote:
> just want to double check. You are saying, right after coderep creation,
> the I8 const appeared?
> Sun
>
> On Tue, Nov 29, 2011 at 11:39 AM, Gang Yu <yugang...@gmail.com> wrote:
>
>> Sun,
>>
>> Before SSA, the whirl input for the statement
>>
>> ---- BB3 (RPO 3) (LOGIF) (e) LINE 10 (rid_id:0) (flag:7)
>> Preds:2
>> Succs:9 4
>> Fallthrough: 4
>> Next : BB4
>> Prev : BB2
>> dom_dfs_id(0), dom_dfs_last(0)
>> pdom_dfs_id(0), pdom_dfs_last(0)
>> U4U4LDID 0 <st 3> T<8,.predef_U4,4>
>> I4INTCONST 1 (0x1)
>> I4I4LDID 0 <st 4> T<4,.predef_I4,4>
>>
>> I4SHL
>> I4INTCONST -1 (0xffffffffffffffff)
>> I4ADD
>> U4I4CVT
>> U4U4LDID 0 <st 3> T<8,.predef_U4,4>
>> U4BAND
>> I4U4EQ
>> FALSEBR L1538 {line: 0/0} {freq: 0, ln: 0, col: 0}
>> after codemapped, the wrong output
>> ---- BB3 (RPO 3) (LOGIF) (e) LINE 0 (rid_id:0) (flag:207)
>> Preds:2
>> Succs:9 4
>> Fallthrough: 4
>> Next : BB4
>> Prev : BB2
>> Idom : BB2
>> Ipdom : BB9
>> dom_dfs_id(2), dom_dfs_last(9)
>> pdom_dfs_id(2), pdom_dfs_last(4)
>> 9 4
>> Pdom :2
>> Dom Frontier :4 {}
>> RCFG Dom Frontier :4 {}
>> > LDID U4 U4 sym3v3 0 ty=802 <u=4 cr12> flags:0x0 b=-1 #max_time_incr
>> > LDID U4 U4 sym3v3 0 ty=802 <u=4 cr12> flags:0x0 b=-1 #max_time_incr
>>
>> > LDC I8 -2147483649 <u=1 cr17> flags:0x0 b=-1
>> > U4BAND <u=1 cr18> isop_flags:0x0 flags:0x0 b=-1
>> > I4U4EQ <u=1 cr19> isop_flags:0x0 flags:0x0 b=-1
>> >OPR_FALSEBR 1538 b=-1 flags:0x2 pj2 Sid-1
>> let me know if you have other dump request
>>
>>
>> Regards
>> Gang
>>
>>
>> On Tue, Nov 29, 2011 at 11:10 AM, Sun Chan <sun.c...@gmail.com> wrote:
>>
>>> 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
