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
