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
