thx!
Pls go ahead
Sun
On Sat, Dec 17, 2011 at 4:31 AM, Ye, Mei <mei...@amd.com> wrote:
> Here is a fix:****
>
> The problem is that the code below does not anticipate the situation that
> a condition-expression is a constant, or in general, has no kids.****
>
> ** **
>
> Index: be/opt/opt_proactive.cxx****
>
> ===================================================================****
>
> --- be/opt/opt_proactive.cxx (revision 3851)****
>
> +++ be/opt/opt_proactive.cxx (working copy)****
>
> @@ -3210,7 +3210,7 @@****
>
> ****
>
> if (!no_alias) {****
>
> if (!do_query && (_action == DO_IFFLIP)) {****
>
> - WN * wn_tmp = WN_kid0(expr1);****
>
> + WN * wn_tmp = (WN_kid_count(expr1) > 0) ? WN_kid0(expr1) : NULL;***
> *
>
> if (wn_tmp) {****
>
> BOOL result1 = FALSE;****
>
> BOOL result2 = FALSE;****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* Sun Chan [mailto:sun.c...@gmail.com]
> *Sent:* Friday, December 16, 2011 3:29 AM
> *To:* Gang Yu
> *Cc:* open64-devel
> *Subject:* Re: [Open64-devel] Review request for bug934(regression fix
> for r3843)[WOPT]****
>
> ** **
>
> how about fix proactive_opt (or whatever the name is)? It is something
> added not too long ago****
>
> Sun****
>
> On Fri, Dec 16, 2011 at 6:27 PM, Gang Yu <yugang...@gmail.com> wrote:****
>
> Hi, Sun****
>
> ****
>
> Would you please kindly furthur input to this issue? If we could not
> find alternative better fix, can we check in the patch firstly? the
> regression bugs are marked major priority, we should get it fixed quickly.
> ****
>
> ****
>
> Thanks****
>
>
> Regards
> Gang
>
> ****
>
> On Thu, Dec 15, 2011 at 10:19 AM, Gang Yu <yugang...@gmail.com> wrote:****
>
> Thanks for your comments.****
>
> On Wed, Dec 14, 2011 at 10:06 PM, Sun Chan <sun.c...@gmail.com> wrote:****
>
> I don't understand the rationale for this fix. You are saying that the
> dead branch is not dce'd, and lno does not like it. So, why not fix dce? A
> dead branch is dead branch, why this workaround?****
>
> Sun****
>
> ****
>
> This segmentation is in the preopt, but intermediate optimized result as:*
> ***
>
> IF {line: 1/131}
> U4INTCONST 1 (0x1)
> THEN
> ...****
>
> ELSE****
>
> BLOCK****
>
> END_BLOCK****
>
> END_IF****
>
> is acceptable, not 100% optimized but still in its own right and later
> mainopt can still eliminate the dead branch.****
>
> ****
>
> for a long term, we should fix proactive_loop_transform, since we should
> not always assume the intermediate input in perfect form.****
>
> ****
>
> Coding style in open64.net pointing this out:****
>
> ****
> no assumption across****
>
> - No assumption across different phases****
>
> ****
>
> As a temporary workaround, we assume the previously code work quite well
> except for cases like bug912, so, we make more effort on limit the changes,
> i.e, more constraint on the change. if we add the MAINOPT condition, the
> branch get eliminted by later DCE in preopt, then proactive_loop_transform
> happy. we get things done.****
>
>
> Regards
> Gang
> ****
>
> On Wed, Dec 14, 2011 at 12:34 PM, Gang Yu <yugang...@gmail.com> wrote:**
> **
>
> Hi,****
>
> ****
>
> Would a gatekeeper please help review the fix for bug934 , regression
> caused by r3843?****
>
> ****
>
> segment-fault function snippet of bug case:****
>
> ****
>
> void LibRaw:: tiff_set (ushort *ntag,
> ushort tag, ushort type, int count, int val)
> {
> struct tiff_tag *tt;
> int c;
> if (type < 3 && count <= 4)
> for (c=0; c < 4; c++) tt->val.c[c] = val >> (c << 3);
> }
> void LibRaw:: tiff_head (struct tiff_hdr *th, int full)
> {
> if (full) {
> tiff_set (&th->ngps, 3, 2, 2, (imgdata.other.gpsdata)[30]);
> tiff_set (&th->ngps, 4, 5, 3, ((char *)(&(th->gps[6])) - (char *)th));
> tiff_set (&th->ngps, 5, 1, 1, (imgdata.other.gpsdata)[31]);
> }
> int c, row, col, soff, rstep, cstep;
> for (row=0; row < (imgdata.sizes.height); row++, soff += rstep) {
> }
> }****
>
> ****
>
> at O3 , tiff_set is inlined into tiff_set, at PREOPT_LNO_PHASE,
> expression ****
>
> if (type <3 && count <=4), i.e, whirl expression****
>
> ****
>
> U4U2LDID 0 <st 89> T<7,.predef_U2,2>
> U4INTCONST 2 (0x2)
> U4U4LE
> I4I4LDID 0 <st 90> T<4,.predef_I4,4>
> I4INTCONST 4 (0x4)
> U4I4LE
> I4CAND
> U4I4CVT****
>
> after codemap, is transfered to****
>
> > LDC U4 1 <u=2 cr19> flags:0x0 b=-1
> > U4I4CVT <u=2 cr33> isop_flags:0xc0000 flags:0x1 b=-1
> >OPR_FALSEBR 6914 b=-1 flags:0x2 pj2 Sid-1****
>
> DCE does not delete the unreachable branch under this condition, which
> then emits back to H whirl****
>
> as****
>
> IF {line: 1/131}
> U4INTCONST 1 (0x1)
> THEN
> ...****
>
> ELSE****
>
> BLOCK****
>
> END_BLOCK****
>
> END_IF****
>
> ****
>
> this will make proactive transformation phase in PREOPT_LNO1_PHASE
> uncomfort, then it asserts.****
>
> ****
>
> Suggested patch, keep the orginal handling of U4I4CVT const , only change
> under the MAINOPT_phase.****
>
> ****
>
> ****
>
> osprey/be/opt/opt_htable.cxx -- 148c4e2..6499b99 100644
> --- a/osprey/be/opt/opt_htable.cxx
> +++ b/osprey/be/opt/opt_htable.cxx
> @@ -2273,7 +2273,9 @@ CODEMAP::Canon_cvt(WN *wn,
> Get_mtype_class(OPCODE_desc(op))) != 0 &&
> 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 &&
> + // bug934 open64.net. Only do this at MAINOPT_PHASE.
> + (!(_phase == MAINOPT_PHASE &&
> + OPCODE_rtype(op) == MTYPE_U4 &&
> OPCODE_desc(op) == MTYPE_I4 &&
> ccr->Tree() == NULL)))
> return propagated;****
>
> ****
>
> Would a gatekeeper help a review? ****
>
> ****
>
> BTW, thanks for Xiaojing for report the bug.****
>
>
> Regards
> Gang****
>
> ** **
>
>
> ------------------------------------------------------------------------------
> Cloud Computing - Latest Buzzword or a Glimpse of the Future?
> This paper surveys cloud computing today: What are the benefits?
> Why are businesses embracing it? What are its payoffs and pitfalls?
> http://www.accelacomm.com/jaw/sdnl/114/51425149/
> _______________________________________________
> Open64-devel mailing list
> Open64-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/open64-devel****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
------------------------------------------------------------------------------
Learn Windows Azure Live! Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for
developers. It will provide a great way to learn Windows Azure and what it
provides. You can attend the event by watching it streamed LIVE online.
Learn more at http://p.sf.net/sfu/ms-windowsazure
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
