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
