>
> On Thu, Oct 27, 2011 at 5:25 AM, Min Zhao wrote:
>>
>> Hi Hui,
>>
>> Your change looks good to me in general. I agree with your approach to
>> have one NystromAliasAnalyzer in IPA phase, most importantly having
>> one alias tag map, which makes alia
Hi Hui,
Your change looks good to me in general. I agree with your approach to
have one NystromAliasAnalyzer in IPA phase, most importantly having
one alias tag map, which makes alias query for WNs in different PUs
easy. Just some minor comments:
1) You have some places to access the data member
Hi,
I reviewed this change and Xing already incorporate my comments into the patch.
Michael,
Since this patch is inside IPA, would you please also take a look?
Really appreciated your comments.
Min
On Sat, Oct 22, 2011 at 10:44 PM, Xing Zhou wrote:
> Hi,
> Here is the patch for siloed refere
ither -1 or 0.
>
> Here is the new patch
>
> On Fri, Aug 19, 2011 at 3:37 AM, Min Zhao wrote:
>> Hi Yongchong,
>>
>> I looked at your fix for ia64. A couple of comments:
>> 1) For the first part of the fix, is I4NEG the only place that could
>> have problem? H
Hi Mei,
Your new patch looks good to me.
Thanks,
Min
On Mon, Aug 22, 2011 at 12:16 PM, Ye, Mei wrote:
> Hi Min
>
> Thanks a lot for your review. Attached patch combines two parts together.
> W.r.t to why the last check of Postdominates is needed, consider a Fortran
> code like below:
>
>
Hi Mei,
Your code looks OK to me, except one comment:
why not combining two parts (i.e., not allow entrances check and
dominates/postdominates check) under (bb_tmp != bb_first) into one?
Also why we need the very last check !bb_tmp->Postdominates(bb_first)?
Thanks,
Min
On Tue, Aug 16, 2011 at
Hi Yongchong,
I looked at your fix for ia64. A couple of comments:
1) For the first part of the fix, is I4NEG the only place that could
have problem? How about other I4XXX, like I4ABS?
2) For the second part of the fix, I think your first version is good
enough. Why we need to have special handli
ri, Aug 12, 2011 at 6:10 PM, Sun Chan wrote:
> the accuracy is controlled by round_off etc, O2, O3, .. etc are tied
> with roundoff, iEEE internal flags
> the fp-accuracy is just a gcc option
>
> On Sat, Aug 13, 2011 at 6:07 AM, Min Zhao wrote:
>> Hi Ram,
>>
>> I wa
Hi Ram,
I was going to use -fp-accuracy option. I found it is very
counter-initutive when "-fp-accuracy=relaxed" means less fp freedom
but more fp accuracy. "relaxed" does not sound like improving accuracy
at all.
Can we change the setting of -fp-accuracy to be more easily
understandable, like "s
Hi Sun,
According to WHIRL specification, cand/cior is VH-H level IR, which
should be lowered before WOPT (PRE), right?
Thanks,
Min
On Wed, Jul 13, 2011 at 4:54 AM, Sun Chan wrote:
> if cand/cior is not lowered, sure PRE will be able to do the CSE. What
> you are seeing is that someone changed
Hi,
Although I'm not a gatekeeper in CG, I looked at the patch.
One minor comments: In barcelona_si.cxx, there is redundant definition:
@@ -143,6 +149,10 @@
TOP_or16,
TOP_or32,
TOP_or64,
+ TOP_ori8,
+ TOP_ori16,
+ TOP_ori8,
+ TOP_ori16,
As you said, there are a lot of duplicate information amon
Your change looks good to me. Pls go ahead.
Thanks,
Min
On Mon, May 23, 2011 at 12:14 PM, Ye, Mei wrote:
>
>
> in "CFG::Remove_bb", When an EH region end block is removed, we did not
> provide a new region end. This fix identifies whether the BB to be deleted
> is an EH region end. If so, we
I agree -OPT:alias=field_sensitive is more meaningful.
Thanks,
Min
2011/5/11 Christopher Bergström
> On Wed, May 11, 2011 at 4:08 PM, Hui Shi wrote:
> > Hi All,
> > 2. It use Nystrom's last name without his permission?
>
> It's a very popular Swedish last name and you almost certainly don't
>
It looks good to me.
Thanks,
Min
On Fri, Apr 29, 2011 at 12:14 AM, Hui Shi wrote:
> Would gatekeeper help review this patch?
>
> https://bugs.open64.net/show_bug.cgi?id=765
> Nystrom alias issue: sig fualt in ConstraintGraph::handleMemcopy
>
> Test case is memcpy without arguments generated in
It looks good to me. Please go ahead.
Thanks,
Min
On Fri, Apr 29, 2011 at 1:43 AM, Hui Shi wrote:
> Would gatekeeper help review this patch?
> https://bugs.open64.net/show_bug.cgi?id=766
> Nystrom alias issue: deadlock in nystrom alias processInito
>
> Nystrom has sig fault when a dead lock ha
Hi,
Your change look OK to me. Since it is a relative big functionality, would
you please update at:
http://wiki.open64.net/index.php/ActiveDevelopment. It would be good if you
have some motivating examples and design doc.
Thanks,
Min
On Mon, Apr 25, 2011 at 5:04 PM, Ye, Mei wrote:
> Add e
Your change look fine to me.
Thanks,
Min
On Wed, Apr 13, 2011 at 6:24 PM, Lai, Michael wrote:
> Can a gatekeeper review the following change?
>
>
>
> This change affects the existing "array remapping" optimization.
>
> The following change adds a restriction to exclude arrays with
>
> non-zer
I looked at the patch. It looks fine with me.
Thanks,
Min
On Fri, Apr 8, 2011 at 1:19 PM, David Coakley wrote:
> Could a gatekeeper please review the attached patch from the AMD team?
>
> It improves some specific optimizations for C++ programs. The code
> changes are mostly in the area of IP
Hi,
Would a gatekeeper please review my change for bug761?
https://bugs.open64.net/show_bug.cgi?id=761
(256.bzip2 assertion failure in DBG built compiler when WSSA enabled).
The assertion happens in verifying the live range:
##Assertion failure at line 883 of opt_verify.cxx
### sym20v2(cr
Hi,
Would a gatekeeper please review my change for bug 759?
https://bugs.open64.net/show_bug.cgi?id=759
The issue is segmentation fault in DCE when we turned on WSSA for compiling
254.gap.
The problem seems obvious. Inside the opt_dce.cxx (Remove_dead_statements),
it examines
"bb->Succ()->Node()
Hi Sun,
Since we are going to turn on CPIC, we want to make sure CG is doing the
right job. Currently, it seems that CG does not handle CPIC well (for
example x8664/exp_loadstore.cxx does not handl CPIC at all).
Thanks,
Min
On Sun, Feb 27, 2011 at 10:42 PM, Sun Chan wrote:
> I don't understan
Hi,
Would a gatekeeper please review the fix for bug 712?
https://bugs.open64.net/show_bug.cgi?id=712
The assertion happens in the code of Process_Formal_ST (ipo_inline.cxx) when
the fixup method for the formal is FM_REPLACE_ACTUAL (i.e., formal replaced
by the actual parameter).
2813
in opt_ssa.cxx (starting line 1595):
1589 //
===
1590 // Resurrect_chi - A chi node that was dead has to be resurrected
1591 // because ILOAD to LDID folding introduces a real use of the result
of the
1592 // chi; need
clude the code in iload folding that tries to do the same
> thing, i.e. resurrect the version?
> Thx!
> Su
>
> On Thu, Feb 10, 2011 at 8:08 AM, Min Zhao wrote:
> >
> > Yes.
> >
> > On Wed, Feb 9, 2011 at 4:08 PM, Sun Chan wrote:
> >>
Yes.
On Wed, Feb 9, 2011 at 4:08 PM, Sun Chan wrote:
> S2 doms S5?
> Sun
>
> On Thu, Feb 10, 2011 at 7:55 AM, Min Zhao wrote:
> >
> > Sorry, I should NOT use v0 as an example version. For better explanation,
> > using the real verions in the code:
> >
&
st a
> versioning problem. It is a precision problem, isn't it?
> Sun
>
> On Thu, Feb 10, 2011 at 2:56 AM, Min Zhao wrote:
> > More explanations.
> >
> > Here is the failing test case:
> >
> > S1: loc = 0;
> >
> > S2: buffer[limit] = 33;
> &
More explanations.
Here is the failing test case:
S1: loc = 0;
S2: buffer[limit] = 33;
sym3v1 = chi (sym3v0) // buffer
sym5v1 = chi (sym5v0) // buffer scalar var -> NOT LIVE by DSE ->
LIVE by ILOAD_FOLD
S3: if (buffer[loc] != 10)
mu(sym3v1) // change
Hi,
Would please a gatekeeper review my fix for bug 717?
https://bugs.open64.net/show_bug.cgi?id=717
The problem happens in setting/resetting the flag ISOP_INVARIANT_VISITED.
This flag is used in Invariant_cr and Invariant_cr_rec (opt_loop.cxx) to
remember the OPs found to be loop invariant (t
Hi,
Would a gatekeeper please review my change for bug700?
The assertion (invalid option) happens when the file name is driver-***.c
(while driver is a component name).
The problem is in newly checked-in componentization code for processing the
option (r3390).
I tried to process the option
Hi,
Would a gatekeeper please review my fix for bug629?
https://bugs.open64.net/show_bug.cgi?id=629
The assertion happens in opt_htable.h (#981), because Const_val expects a
CK_CONST.
The root cause for the problem is inside the simplifier (wn_simp_code.h).
Inside SIMPNODE_SimplifyExp2_h, S
e GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
MA 02110-1301, USA."
Thanks,
Min
2010/11/4 "C. Bergström"
> Min Zhao wrote:
>
>> Thanks for your review. The copyr
Thanks for your review. The copyright for the new files should be:
+ This program is free software; you can redistribute it and/or modify it
+ under the terms of version 2 or above of the GNU General Public License
as
+ published by the Free Software Foundation.
As for the prefix, it was for a
2010/10/18 "C. Bergström"
> Min Zhao wrote:
>
>> Thanks everyone who reviewed the proposal. It seems not much objection.
>> We are going to implement the work as proposed and send out for review when
>> it is ready.
>>
> Was the amount of work to chang
e most appropriate implementation?
> sun
>
> 2010/10/12 "C. Bergström" :
> > Min Zhao wrote:
> >>
> >> Hi,
> >>
> >> We propose to make changes for componentizing optimization phases in
> >> open64 at HP.
> >>
> >> The
Gradually, we will change existing optimizations. With careful
encapsulation, I don't think changing C style phase into C++ code is a
problem.
Thanks,
Min
2010/10/11 "C. Bergström"
> Min Zhao wrote:
>
>>
>> Hi,
>>
>> We propose to make changes for co
Hi,
I reevaluated the fix for this bug (bug611). It seems that we should not
set_TY_return_in_mem for complex return type in wgen. As described in the
comment, the design philosphy seems to be "wgen handles return_in_ memory
based on high-level language requirements and back-end handle handles
ret
I forgot to mention that the change was approved by Jian-Xin Lai.
Thanks,
Min
On Tue, Oct 5, 2010 at 1:27 PM, wrote:
> Author: minz
> Date: 2010-10-05 16:27:56 -0400 (Tue, 05 Oct 2010)
> New Revision: 3366
>
> Modified:
> trunk/osprey/wgen/wgen_expr.cxx
> Log:
> Fix for bug664:
>
> The asser
Hi,
Would a gatekeeper please review the change for bug664?
https://bugs.open64.net/show_bug.cgi?id=664
Here is the failing testcase:
struct st1{
int *a;
int b;
};
int main()
{
struct st1 myst;
myst.b = 10;
int k;
k = (0, myst).b;
printf("%d\n", k);
}
We are generating incorrect IR for c
Hi Yongchong,
Sorry for the late reply, since I was on vacation last week. I'll fix it
ASAP.
Thanks,
Min
On Sat, Sep 25, 2010 at 1:14 AM, Wu Yongchong wrote:
> Hi, min
> I have filed a bug in http://bugs.open64.net/show_bug.cgi?id=662
> This is a regression of your checkin in revision 3347, w
Hi,
Would a gatekeeper please review my fix for bug600:
https://bugs.open64.net/show_bug.cgi?id=600
Please check the bug report for the failing example (since it is long to
show).
The gspin tree of the failing example has the following pattern:
...
@gs_constructor_elts_value CONS<717520>
Hi,
Would a gatekeeper please review my fix for bug 611:
https://bugs.open64.net/show_bug.cgi?id=611
The failing case is shown as following. It asserts when compiled in –m32.
typedef __complex__ double cdouble;
cdouble to_complex(double r) {
cdouble z;
__real__ z = r;
return z;
}
you can grep for all occurences of "mtype == MTYPE_C4" in wgen
> and see if there is still other places needed fixing.
> Yes, since the C8, c10 are now first class citizens, mmiload is not
> appropriate (only for user defined types)
> Sun
>
> On Wed, Sep 8, 2010 at 7
Hi,
Could a gatekeeper please review my fix for bug 593?
https://bugs.open64.net/show_bug.cgi?id=593
Here is the example for the failing case:
1. _Complex long double cd = 234.0L + 0x0.abcp-70L + 567.0Li +0x0defp-70Li;
2. void complexlongdouble_i_fv (int n, ...) {
3. __builtin_va_list ap;
4.__b
43 matches
Mail list logo
