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
