Thanks Min.
Since this is not criticial bug fixing, I plan to check in after 5,0
release.
Regards
Shi Hui
On Sat, Oct 29, 2011 at 2:06 AM, Min Zhao wrote:
> Your new patch looks good to me. Please go ahead.
>
> Thanks,
>
> Min
>
> On Wed, Oct 26, 2011 at 9:40 PM, Hui S
ause problem, because in IPA_WN_MAP_Delete, it only free
memory when pool is Malloc_Mem_Pool.
Otherwise it will free the already freed memory.
Fix the order of WN_MAP delete.
>
> Thanks,
>
> Min
>
> On Thu, Jul 28, 2011 at 12:43 AM, Hui Shi wrote:
> > Hi, All
> >
>
Hi, All
Can gatekeepers help review this patch?
When apply option -OPT:alias=field_sensitive -IPA:preopt=on, compiler will
assert in NystromAliasAnalyzer.
NystromAliasAnalyzer assumes it is in be phase and try to get the IPA
constraint graph summary from IR file.
To enable nystrom alias analyzer
18 AM, Fred Chow wrote:
> **
> My comments below:
>
>
> On 07/23/2011 09:00 AM, Hui Shi wrote:
>
> Hi Fred,
>
> Thanks for your comments.
> Comments below.
>
> On Sat, Jul 23, 2011 at 8:04 PM, Fred Chow wrote:
>
>> Hi Shi,
>>
>> Your change to f
f the _vse_required_set, which I understand is for finding
> more dead stores. More below:
>
>
> On 07/22/2011 01:50 AM, Hui Shi wrote:
>
> Hi Fred,
>
> Follow your suggestion, if one chi node is live, other aliased chi nodes in
> same chi_list should live.
> I fix
out what the root problem is. At least the version I worked with at
> PathScale does not have this problem. I would welcome others to provide
> input on this.
>
> Fred
>
>
> On 07/04/2011 07:37 PM, Hui Shi wrote:
>
> Hi Fred,
>
> Thanks for your comments.
> The
thScale does not have this problem. I would welcome others to provide
> input on this.
>
> Fred
>
>
> On 07/04/2011 07:37 PM, Hui Shi wrote:
>
> Hi Fred,
>
> Thanks for your comments.
> The reanming happens only when there are some dead phi/chi nodes revive in
> CODEM
vsym which appears in the mu of STMT2. So your fix
> should be in preventing the copy propagation.
>
> Fred
>
>
> On 06/29/2011 11:35 PM, Hui Shi wrote:
>
> Could gatekeeper help review this fix?
>
> In SSA::Create_CODEMAP ILOAD folding is performed during coderep setu
Add an updated patch.
After discuss with An Xiaomi. Remove An's previous fix for bug#707.
On Thu, Jun 30, 2011 at 10:58 PM, Ye, Mei wrote:
> I am on vacation today and tomorrow. Can other gatekeepers review this?
> Thx.
>
> ** **
>
> -Mei
>
> ** **
>
Could gatekeeper help review this fix?
In SSA::Create_CODEMAP ILOAD folding is performed during coderep setup.
The problem is iload folding may revive some dead phi/chi node.
For example
STMT1
sym2v4 = chi(sym2v3) NOT LIVE
default_vsym_v4 = chi(default_vsym_v3) LIVE
STMT2
ILOAD mu(default
Would gatekeepr help reveiew this patch?
Currently, nystrom alias analyzer analyze again for OpenMP lower created
parallel PU.
And when OpenMP lower create this parallel PU, it doesn't copy aliasTagMap.
This problem is when creating constraint graph for OpenMP parallel PU.
Compilation has sig fau
Hi, All
Can gatekeeper help review this patch?
For attached test case, in foo, *p reference is not alias with a in nystrom
alias analysis.
The problem is when creating alias tag, alias_tag points to blackhole is not
updated correctly.
Alias dump before fix.
I4INTCONST 2 (0x2) {cgnode 1}
I4STI
Hi All,
Would gatekeeper help review this patch?
This patch is adding function for nystrom alias triage.
I use this triage method find the nystrom problem in bug767.
https://bugs.open64.net/show_bug.cgi?id=767
If have a testcase pass with current alias analysis while fail at nystrom
alias.
We nee
eld_sensitive", len) == 0) {
Alias_Nystrom_Analyzer = TRUE;
} else {
ErrMsg ( EC_Inv_OPT, "alias", val );
Regards
Shi Hui
2011/5/12 Min Zhao
>
> I agree -OPT:alias=field_sensitive is more meaningful.
>
> Thanks,
>
> Min
>
> 2011/5/11 Christopher Bergström
&
Hi All,
The problem of using -OPT:alias=nystrom is
1. Nystrom is not intuitive for open64 user to know what this alias option
really means.
It's not a common alias terminology.
What is this alias analysis's capabitlity?
If used in CPU2006 SPEC report later, it's not clear and may be tr
I have file a bug for this issue
https://bugs.open64.net/show_bug.cgi?id=775
On Thu, May 5, 2011 at 4:46 PM, Hui Shi wrote:
> This assertion exposes a real issue in LNO.
> Code updating integer constant WN node is incosistent with
> WN_CreateIntconst.
>
> In WN *WN_CreateIntcon
in.
>
> 2011/4/29 Hui Shi
>
>> Would gatekeeper help review this patch?
>>
>> https://bugs.open64.net/show_bug.cgi?id=767
>> Nystrom alias issue: 456.gobmk base output difference on train data
>>
>> The wrong alias is caused in
>> ConstraintGraphNode::
Would gatekeeper help review this patch?
https://bugs.open64.net/show_bug.cgi?id=769
Nystrom alias issue: OMPM2001 assert "the child mp pu pool is not equal to
_memPool"
This assert happens because,
in AliasAnalyzer::~AliasAnalyzer, assume lower_mp will always copy parent
PU's aliasTagMap to chil
This assertion exposes a real issue in LNO.
Code updating integer constant WN node is incosistent with
WN_CreateIntconst.
In WN *WN_CreateIntconst(OPERATOR opr, TYPE_ID rtype, TYPE_ID desc, INT64
const_val)
U4intconstant is truncated to 32 bit value.
if (opc == OPC_U4INTCONST) {
#ifndef TARG_X86
sorry for your trouble.
I have already submit code review request for this issue.
"Code review request for open64 debug build failure with r3574"
And freq has give some comments on fall through switch case. You can try the
last patch in that thread.
On Tue, May 3, 2011 at 9:20 AM, Gilmore, Doug
of this in the files you're
> modifying.
>
> Fred
>
>
> On 04/29/2011 07:19 AM, Hui Shi wrote:
>
> Hi Fred,
>
> if (((mINT32)TCON_v0(*tc)) >= 0), it will not break out of switch and fall
> through code to check v1, v2, v3 be zero.
> case MTYPE_U1:
>
Would gatekeeper help review this patch?
https://bugs.open64.net/show_bug.cgi?id=768
Nystrom alias issue: sig fualt in ipa_link when connecting parameters
See bugzilla for test case and compliation command line.
function _ZNV2c52f7Ez c5::f7(...) volatile is defined in both
alias_vararg1.c and ali
ge as what the original code
> intended.
>
> Fred
>
>
> On 04/28/2011 08:09 PM, Hui Shi wrote:
>
>
> Would a gatekeeper help review?
> I have update the patch with new error message in attachment.
>
>
> On Thu, Apr 28, 2011 at 1:30 PM, Hui Shi wrote:
>
>> y
Would gatekeeper help review this patch?
https://bugs.open64.net/show_bug.cgi?id=767
Nystrom alias issue: 456.gobmk base output difference on train data
The wrong alias is caused in
ConstraintGraphNode::collapseTypeIncompatibleNodes.
It try to collpase a kid node's parent node into kid.
In Const
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 happens in process_inito.
In following case, the variable is initialized with a pointer to itself.
static struct
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 application configuration
phase.
ConstraintGraph::handleMemcopy didn't handle this case.
Fix i
Would gatekeeper help review this patch?
https://bugs.open64.net/show_bug.cgi?id=764
Nystrom alias issue: Assertion failure "alloca with non-KIND_POINTER result
expected to have0 byte
ConstraintGraph::handleAlloca(WN *stmt) assume stmt
assign allocated result direclty to a pointer type symbol, o
Would a gatekeeper help review?
I have update the patch with new error message in attachment.
On Thu, Apr 28, 2011 at 1:30 PM, Hui Shi wrote:
> you're right.
>
> I'll change message to "TCON_v1 not-sign extend result or High order word
> of %s TCON non zero"
&g
;
> On Thu, Apr 28, 2011 at 1:09 PM, Hui Shi wrote:
>
>>
>> Would gatekeeper help review this fix?
>>
>> I1,I2,I4 will be sign extend to I8 and store in TCON_I8,
>> So when I1,I2,I4 is negative, TCON_V1 can be 0x. So the following
>> assertion cond
Would gatekeeper help review this fix?
I1,I2,I4 will be sign extend to I8 and store in TCON_I8,
So when I1,I2,I4 is negative, TCON_V1 can be 0x. So the following
assertion condition is not correct.
Is_True ( (TCON_v1(*tc)|TCON_v2(*tc)|TCON_v3(*tc)) == 0,
("High order word
Would gatekeeper help review this patch?
The priorty of bitwise operator is lower than relational operaotr.
So following code has potential problem.
In Check_TCON ( TCON *tc )
Is_True ( TCON_v1(*tc)|TCON_v2(*tc)|TCON_v3(*tc) == 0,
("High order word of %s TCON non zero %x",
Would a gatekeeper please review this change?
In Hash_TCON, there exist an expression has no effect.
case MTYPE_V32F4:
case MTYPE_V32F8:
hash += TCON_v0(*t) + TCON_v1(*t) + TCON_v2(*t) + TCON_v3(*t);
TCON_v4(*t) + TCON_v5(*t) + TCON_v6(*t) + TCON_v7(*t);
break;
T
Could a gatekeeper please review this patch?
https://bugs.open64.net/show_bug.cgi?id=760
ConstraintGraph::processFlatInitvals is invoked when INITO
isFlatArrayOrStruct, this includes INITVKIND_VAL, INITVKIND_PAD and
INITV_BLKIsFlat.
However in ConstraintGraph::processFlatInitvals it only allow fo
Could a gatekeeper please review this patch?
https://bugs.open64.net/show_bug.cgi?id=753
There are two main issue in ConstraintGraph::processInito and
ConstraintGraph::processInitv
1. In ConstraintGraph::processInito, mem_pool is initialized and not deleted
at early exit point. Cause some mem_pool
Could a gatekeeper please review this patch?
https://bugs.open64.net/show_bug.cgi?id=752
The assertion happens when finding node point to a collapsed node. Collapsed
node is supposed to be not used in constraint graph analysis and points to.
Follow the attached test case in bug report.
In foo
col
Could a gatekeeper please review this patch?
https://bugs.open64.net/show_bug.cgi?id=751
This assertion happens when StInfo::alignOffset doesn't return a
pointer_size aligned offset constraint graph node.
The bug is quite direct in StInfo::alignOffset
// If the offset is already aligned to Pointer
Could a gatekeeper please review this patch?
https://bugs.open64.net/show_bug.cgi?id=750
See case attached in bug report.
This happens because s2.b1m reference in s2 = s1 is through vtable, it is
not aliased with directly filed access s2.b1m in if condition. Then WOPT
propagate s2.b1m’s init value
Could a gatekeeper please review this patch?
APO Ofast assertion, no constraint graph for OpenMP lower generated PU
https://bugs.open64.net/show_bug.cgi?id=749
Assert in ConstraintGraph::buildCGFromSummary, can't find PU's constraint
graph info in IPA output IR file.
APO transformation will insert
Could a gatekeeper please review this patch?
https://bugs.open64.net/show_bug.cgi?id=748
When turn on nystrom alias analyzer, SPEC2006 base 445.gobmk assertion in
ConstraintGraph::buildCGipa, constraint_graph.cxx:444
if (pNode->checkFlags(CG_NODE_FLAGS_COLLAPSED)) {
FmtAssert(pNode !
(fld)),memPool);
}
On Wed, Apr 6, 2011 at 9:14 AM, Hui Shi wrote:
> Could a gatekeeper please review this patch?
> https://bugs.open64.net/show_bug.cgi?id=747
>
> Signal Floating point exception in phase Data Layout
> Exception happens in StInfo::applyModulus(UINT32 offset
Could a gatekeeper please review this patch?
https://bugs.open64.net/show_bug.cgi?id=747
Signal Floating point exception in phase Data Layout
Exception happens in StInfo::applyModulus(UINT32 offset, UINT32 &start),
modulus value is zero.
In test case struct M's size is 0. Then when setup the child
> can you give some description of the phase ordering of this points to
> vs inline etc?
> Sun
>
> On Sat, Apr 2, 2011 at 11:16 AM, Hui Shi wrote:
> >
> > forget to send all.
> > -- Forwarded message --
> > From: Hui Shi
> > Date: Fri, A
forget to send all.
-- Forwarded message --
From: Hui Shi
Date: Fri, Apr 1, 2011 at 8:15 PM
Subject: Re: [Open64-devel] Review request for nystrom inline support,
improves points to analysis after inline.
To: Sun Chan
sorry. I convert it to a pdf document.
On Fri, Apr 1, 2011
Can gatekeeper help review this fix?
loop multi-version maintain CFG has bug, cause assertion when emit WHIRL
tree.
https://bugs.open64.net/show_bug.cgi?id=754
Loop multi-version transformation insert a pre-condition BB before
loop header BB.
If loop header BB is if_BB’s merge BB, need change i
iable names like "sentive", there is not
> > much a gatekeeper can do. Also, the IPA already does call site
> > specific inlining, and you are introducing a new term context
> > sensitive inlining, not sure what you meant. Please clarify.
> > I suggest (if you ha
Can gatekeeper help review this fix?
Build error after check in new alias on IA64.
checking PLOC type, PLOC structrue on IA64 has 4 fields.
typedef struct {
PREG_NUM reg;
#if defined(TARG_X8664) || defined(TARG_IA32)
PREG_NUM reg2;/* for second register used in passing a struct */
#end
Can gatekeeper help review this patch?
This is a bug in cflow optimization exposed when a cmpi32 is changed to
cmpi8
int main()
{
long long ll = 0x7EF0LL;
unsigned char c = (char) ll;
if (c != 0xf0)
return 1;
return 0;
}
opencc -O0, run result's value is 0.
opencc -O1, run result's value is 1.
Hi All,
Find_Freq_LMV_Predecessors's code has a obvious problem for do loop at line
freq.cxx:1588.
do {
// get BB's predecessor count
if(predecessor count is 2) {
// then branch
on some condition break;
match_pattern = TRUE.
}
} while(match_pattern);
the ma
Can gatekeeper help review this problem?
Index: ../osprey/be/cg/x8664/cgemit_targ.cxx
===
--- ../osprey/be/cg/x8664/cgemit_targ.cxx (revision 1187)
+++ ../osprey/be/cg/x8664/cgemit_targ.cxx (working copy)
@@ -973,9 +973,9
Hi All,
Can gatekeeper help review this fix?
_mm_slli_si128(v2, 1), the imm value 1 is sfhit byte count.
both gcc and open64 preprocess are
v3 = ((__m128i)__builtin_ia32_pslldqi128 (v2, (1) * 8));
// translate byte offset into bit offset.
gcc final code
pslldq $1, %xmm0 // back to
t such do loop guard can't guarantee orig SIMD loop end update is correct.
2010/8/19 Ye, Mei
> Hello Hui Shi
>
> See attached “simd.cxx”, search for “!!!”.
>
> In your example, if start = 0, end = 0, can a change of “i < end” to “ i
> <= end – 1” make a 0-tr
{
>
> ….. --- looks like you miss here.
>
> }
>
> ……
>
> }
>
>
> --
>
> *From:* Hui Shi [mailto:kalin@gmail.com]
> *Sent:* Friday, August 13, 2010 9:29 PM
> *To:* Ye, Mei; Sun Chan
> *Cc:* open64-devel@lists.sourceforge.net
> *Subject:* Re: [Open64-devel]
bug in handling unsigned
> > comparison loop end
> >
> >
> >
> > Mei,
> >
> > See if you can review this changelist. Thanks.
> >
> >
> >
> > Roy
> >
> >
> >
> > From: Hui Shi [mailto:]
> > Sent: Sunday, Augu
Hi, All
Can LNO gatekeeper help review this fix?
This bug happens in -m32 on x8664 linux.
Attached is the test case and patch.
command line is
opencc -O3 unsigned_loop_end.c -INLINE:ne=foo:ne=init:ne=check
-OPT:unroll_times_max=1 -m32
The bug happens when vectorization is happend on following lo
54 matches
Mail list logo
