Since no one attempted, I will give my 2 cents. I haven't been doing
optimization for awhile now, so I could be totally off and what I
suggested have never been tried out.
Note that in a lot of cases (reassoc wrt distribution aside),
equivalent expressions (reassociatable) are by definition follow
is N global?
On Fri, Jun 28, 2013 at 1:14 AM, Yiran Wang yiran.w...@gmail.com wrote:
Thanks for your comments.
No, the assembly looks the same.
Good or bad, the compiler is able to clean up the temporary completely,
say, copy propagation and DSE.
Regards,
Yiran
On Thu, Jun 27, 2013
may be other can check out if my suspiciion is correct. The arrays are
global arrays. By pre-emption rule, they are pre-emptible, meaning
their value can be changed by dependent libraries (shared libraries).
If you use static or local, things should work fine. If my claim
is correct, this is an
Jian-Xin,
Can you take a look at the change?
Thx!
Sun
On Tue, Dec 18, 2012 at 6:22 PM, Christophe MONAT
christophe.mo...@st.com wrote:
Since all the preconditions are met I am ready to deliver:
[ Branch #169742 ] dt25/dev-cleanup-structure
are you sure you want to inline Find_derived_symbol?
Sun
On Wed, Nov 28, 2012 at 11:17 AM, zhangliwei lifelong830...@gmail.com wrote:
Hi,
Could someone review the patch for Bug1011? Thanks very much.
This solution is that when the compiler improves the variable “a” alignment
from 1byte to
instrumentation was covered in a tutorial done at Micro around 2002, I
believe. Check out the tutorials materials in open64 or equivalent
sites
Sun
On Thu, Oct 11, 2012 at 4:56 PM, Ahmad Qawasmeh
ahmadqwasmeh2...@yahoo.com wrote:
Hi everyone,
Is there any documentation for the Instrumentation
if there is any documentation for the instrumentation module such as
the ones for WHIRL or symtab.
Regards,
Ahmad
From: Sun Chan sun.c...@gmail.com
To: Ahmad Qawasmeh ahmadqwasmeh2...@yahoo.com
Cc: open64-devel@lists.sourceforge.net
open64-devel
There is WHIRL version for incompatible WHIRL matching and
identification. What is this new ID is about?
Sun
On Thu, Aug 2, 2012 at 5:05 PM, Jian-Xin Lai laij...@gmail.com wrote:
For the WHIRL ID for debug purpose, I think it's not very useful and
we can fully remove it. Otherwise the IR file
Folks,
Can we NOT argue in the abstract? Can someone put out some code and be
specific, relevant to open64 code?
Thx!
Sun
On Fri, Aug 3, 2012 at 11:04 AM, C. Bergström
cbergst...@pathscale.com wrote:
On 08/ 3/12 06:19 AM, Gilmore, Doug wrote:
-Original Message-
From: C. Bergström
please go ahead
Sun
On Wed, Aug 1, 2012 at 1:17 PM, Jian-Xin Lai laij...@gmail.com wrote:
Hi,
We proposed the following patch to fix the build error introduced by
rev 3993. Could the gatekeeper review this patch? Thank you very much.
Index: osprey/ipa/main/optimize/ipo_inline.cxx
;
}
return i;
}
** **
** **
** **
** **
*发件人:* Shin-Ming Liu [mailto:shinm...@gmail.com]
*发送时间:* 2012年7月16日 11:02
*收件人:* shenrfen
*抄送:* Sun Chan; liwei.zh...@simplnano.com;
open64-devel@lists.sourceforge.net
*主题:* Re: 答复: [Open64-devel] 答复: Code review request : Add
:* 2012年7月16日 10:50
*收件人:* shenrfen
*抄送:* Sun Chan; liwei.zh...@simplnano.com;
open64-devel@lists.sourceforge.net
*主题:* Re: [Open64-devel] 答复: Code review request : Add Location info for
ST(New feature)
** **
Do you report the unitialized variable defined at line 3, with your change
10:50
*收件人:* shenrfen
*抄送:* Sun Chan; liwei.zh...@simplnano.com;
open64-devel@lists.sourceforge.net
*主题:* Re: [Open64-devel] 答复: Code review request : Add Location info for
ST(New feature)
Do you report the unitialized variable defined at line 3, with your change
:* Sun Chan; liwei.zh...@simplnano.com;
open64-devel@lists.sourceforge.net
*主题:* Re: 答复: 答复: [Open64-devel] 答复: Code review request : Add Location
info for ST(New feature)
** **
To echo Sun's question,
What would you do this:
void * foo(bool cond) {
void * ptr
I'm not too familiar with x86 assembly, but I see at least 6
instructions needed (he has unroll max = 1, so assume he doesn't want
vector). Value of x is needed outside of loop.
Sun
On Fri, Jul 13, 2012 at 6:42 AM, shuxin yang shuxin.ope...@gmail.com wrote:
hi buddy, this loop can be vectorized:
.
This is just an example, the real cases may not be able to be vectorized. I
just use the unroll_times_max option to simplify the output a little bit.
Regards,
Yiran
On Thu, Jul 12, 2012 at 3:56 PM, Sun Chan sun.c...@gmail.com wrote:
I'm not too familiar with x86 assembly, but I see at least 6
BTW, if x is needed on return, which instruction is redundant?
Sun
On Fri, Jul 13, 2012 at 7:21 AM, Sun Chan sun.c...@gmail.com wrote:
if x is local and is dead outside of the loop, the add to x should be
eliminated. if not, it is an alias issue
Sun
On Fri, Jul 13, 2012 at 7:12 AM, Yiran
transformations. For example, the loop may be virtually unrolled, reversed,
or even fused with other loops.
So it should not matter here.
I am not sure here though.
Best Regards,
Yiran
On Thu, Jul 12, 2012 at 4:28 PM, Sun Chan sun.c...@gmail.com wrote:
BTW, if x is needed on return
Regards,
Yiran
On Thu, Jul 12, 2012 at 4:28 PM, Sun Chan sun.c...@gmail.com wrote:
BTW, if x is needed on return, which instruction is redundant?
Sun
On Fri, Jul 13, 2012 at 7:21 AM, Sun Chan sun.c...@gmail.com wrote:
if x is local and is dead outside of the loop, the add to x should
, Did you mean add I8U4CVT for
U4SELECT?
I don't quite understand why the cvt here is necessary? could you please
make clear of this?
Thank you very much.
Best regards,
xiao-jing
2012/7/4 Sun Chan sun.c...@gmail.com
ok, for the case u need to add cvt, do you get assertion in cg?
Sun
pair for U4LDC.
After adding U8U4CVT, the cg could generate TN pair since the range is in
U8, so the assert disappeared.
2012/7/11 Sun Chan sun.c...@gmail.com
sorry, I meant #4, you need to add the cvt, should that cause cg to
assert (refer to your very first request for review)? Or you
. There was a lot of
failures if we set the type of the const other than U4/I8.
2012/6/28 Sun Chan sun.c...@gmail.com:
Just do an experiment, turn off this thing for this particular case to
prevent the cvt inserted, see what would
happen?
Sun
On Wed, Jun 27, 2012 at 10:32 PM, Xiaojing Zhang
xiaojing70
that is what I meant, they shouldn't
Sun
On Thu, Jun 28, 2012 at 6:56 PM, Jian-Xin Lai laij...@gmail.com wrote:
They were converted into U4 in HSSA.
2012/6/28 Sun Chan sun.c...@gmail.com:
but it is i8 in this case
Sun
On Thu, Jun 28, 2012 at 6:36 PM, Jian-Xin Lai laij...@gmail.com wrote
if (v == (v 32) 32)
699 _dtyp = MTYPE_U4;
700 else _dtyp = MTYPE_I8;
701 u2.isconst.const_val = v; }
2012/6/27 Sun Chan sun.c...@gmail.com
why should
instrumentation in four phases (VHO, LNO, WOPT, CG). What was
the motivation and driven force? Could you share knowledge or experience on
their pros and cons in reality? And why BEFORE_VHO is set as default
fb_phase?
Thanks a ton!
On Tue, Jun 26, 2012 at 6:20 PM, Sun Chan sun.c...@gmail.com
For the record, these kind of global, static functions instead of class
hierarchy style of implementation is not of the same spirit of
implementation within WOPT.
Other wopt gatekeepers, please watch out for coding style deviation with
existing module. We are also here to keep the code quality of
looks good to me
Sun
On Thu, May 31, 2012 at 8:05 PM, Rao, Shivarama shivarama@amd.comwrote:
Hi,
** **
Could a gatekeeper please review the following changes, which would fix
cmake build under Open64?
** **
The hyperblock scheduler makes the following transformation,
Mei,
I have a question, why is there need for compiler generated temps? What
is that? Compiler generated temps should be PREGs that has no
storage requirements (to me, temps has storage allocation associated)
Sun
On Wed, May 30, 2012 at 4:04 PM, s...@open64.net wrote:
Author: meiye
Date:
phase, now we emit the
section align for all sections, not just .text and .literal, so
function CGEMIT_Align_Section_Once can be removed, at the same time, we
handle differently for BUILD_OS_DARWIN since the asm syntax different.
Regards
Gang
On Fri, May 4, 2012 at 10:15 PM, Sun Chan sun.c
of course you are right. OTOH, I am just referring to Gang's changes that
won't affect either. The reason x86 and ia64 has unalignment diff is due to
the arch for ia64 won't support unaligned access
Sun
On Sun, May 6, 2012 at 12:48 AM, Nelson H. F. Beebe be...@math.utah.eduwrote:
Sun Chan sun.c
can you explain a bit why you change it the way you are now? The diff is
something very minor, thus, should not have caused that many lines of
change.
On Fri, May 4, 2012 at 1:58 PM, Gang Yu yugang...@gmail.com wrote:
Hi,
Could a gatekeeper please help review the fix for bug974(
please go ahead. And good finding :-)
Sun
On Tue, May 1, 2012 at 2:06 PM, Yulei Sui rocky...@gmail.com wrote:
Hello,
There is a simple bug in method Post_dominate in file be/com/cfg_bash.h.
A boolean return value is missed after the do-while loop. Compiler may
generate unexpected
I tend to think you are right, except your stack trace is not helping me to
understand what the problem is.
Can you give a bit explanation that I can relate back to your test case?
Thx!
Sun
On Sun, Apr 29, 2012 at 12:02 AM, shenrfen shenr...@gmail.com wrote:
Hi, all.
I found a bug about
to GCC code to add a name
to temp variables.
So I have tried to explain my reservations, and haven't seen any convincing
reply.
I will let Sun decide on this review.
Thanks,
Gautam
From: Gang Yu yugang...@gmail.com
To: Gautam Chakrabarti gautam.c...@yahoo.com
Cc: Sun Chan sun.c...@gmail.com
write a program with file scope var and part of the name is anon and
see what class you will get with your change
Sun
On Fri, Apr 20, 2012 at 3:05 PM, Gang Yu yugang...@gmail.com wrote:
On Fri, Apr 20, 2012 at 2:38 PM, Sun Chan sun.c...@gmail.com wrote:
It is one thing to allow FE to generate
) {
204 ++anon_num;
205 sprintf(buf, .anonymous.%d, anon_num);
206 return buf;
207 }
this is for generation of anonymous names for the tree, and we should be
able to discriminate.
Regards
Gang
On Fri, Apr 20, 2012 at 7:24 PM, Sun Chan sun.c
looks like you folks are making the binary one monolithic executable, no?
Sun
On Fri, Apr 6, 2012 at 2:41 AM, Gilmore, Doug doug.gilm...@amd.com wrote:
Folks probably noticed that I backed out my make_libdeps rule
change.
I attached a new version of the patch that works with old
versions of
I guess I read wrong. I am not the one to review build makefiles :-)
Sun
On Fri, Apr 6, 2012 at 1:41 PM, Gilmore, Doug doug.gilm...@amd.com wrote:
-Original Message-
From: Sun Chan [mailto:sun.c...@gmail.com]
Sent: Thursday, April 05, 2012 7:19 PM
To: Gilmore, Doug
Cc: open64-devel
ok, i am fine with the change
Sun
On Wed, Apr 4, 2012 at 2:07 AM, Gilmore, Doug doug.gilm...@amd.com wrote:
-Original Message-
From: Sun Chan [mailto:sun.c...@gmail.com]
Sent: Monday, April 02, 2012 5:39 PM
To: Gilmore, Doug
Cc: open64-devel
Subject: Re: [Open64-devel] review
let's go with the simpler one. If other arch have problem, we fix it
Sun
On Wed, Apr 4, 2012 at 8:39 AM, Gilmore, Doug doug.gilm...@amd.com wrote:
We noticed that header file dependencies in the library builds
were not working when building shared objects.
This is a problem with the
looks fine with ebo fix. for the other fix, shouldn't that be inside
x8664? Or at least inside ifdef?
Sun
On Tue, Apr 3, 2012 at 8:34 AM, Gilmore, Doug doug.gilm...@amd.com wrote:
This patch fixes initializations of several MEM_POOLs in
ebo_special.cxx, which eliminates many memory pool
please go ahead
Sun
On Fri, Mar 30, 2012 at 1:19 PM, David Coakley dcoak...@gmail.com wrote:
Open64 currently does not build from source on Linux Mint 12 due to
this distro using yet another layout for 64-bit libraries and objects.
The following change corrects the issue by adding another
which part of const_fold functions do you intend to use? Or are you
writing your own? Note also that you will need to observe IEEE
settings for floats
Sun
On Fri, Mar 16, 2012 at 3:55 AM, Gilmore, Doug doug.gilm...@amd.com wrote:
Other Fortran front ends are capable of folding calls to
, 2012 at 4:08 AM, Gilmore, Doug doug.gilm...@amd.com wrote:
-Original Message-
From: Sun Chan [mailto:sun.c...@gmail.com]
Sent: Saturday, March 17, 2012 10:37 AM
To: Gilmore, Doug
Cc: open64-devel
Subject: Re: [Open64-devel] Fix to bug 917
which part of const_fold functions do you
with Doug's forwarded message, I recall the previous conversation.
If we can fix VHO, that should be fine.
The other approach is to distinguish between -O0 vs -O0 -g where the later
will not turn on any optimization, inline ... whatsoever. -O0 really means
-O0 -P:=on, which will do some simple
we are saying, having cg.so depend on wopt.so is NOT the preferred way
and we deliberately desing the compiler NOT this way.
Your claim that things are moving toward statically linked library.
That is not so. You are simply claiming things are moving backward in
time. We deliberately moved to
Very good feedback. We did not design wopt.so to be called by cg.so,
and we never wanted O0 or O1 to run wopt. This same issue has been
argued multiple times in another product compiler elsewhere which I
won't name. Frankly, it's a sloppy feature of gcc, imho.
I would go with Ljx's suggestion of
Initial reaction: this approach is much better fit the design flow of
the entire compiler.
Sun
On Wed, Mar 7, 2012 at 9:17 PM, Gang Yu yugang...@gmail.com wrote:
Hi, list:
We have a new design and implementation for fix the gcc incompatible
issue, tracked as bug798,bug588,..., i,e. open64
Variable Identification(RVI) phase in WOPT
which will obviously increase the register pressures. So, shall we still
apply aggressive preallocation scheduling for IA32 ,PIC which is with very
limited register set?
Thanks
Regards
Gang
On Fri, Feb 24, 2012 at 8:18 PM, Sun Chan sun.c...@gmail.com
I did not review the changes since it's all about removing code, which
is always a good thing. As long as you run enough test (make sure
enough openMP test), I am fine with the check in
Sun
On Mon, Mar 5, 2012 at 4:29 PM, David Coakley dcoak...@gmail.com wrote:
Christopher, thanks for the input,
this is not a bug, you have objects that are compiled -ipa, then later
on decided not to use ipa. Check your makefile, especially the link
line
Sun
On Thu, Mar 1, 2012 at 9:05 AM, Yulei Sui rocky...@gmail.com wrote:
Hello,
I used opencc(stable version 5.0) for compiling some open source
looks good to me
Sun
On Tue, Feb 14, 2012 at 3:18 PM, Gang Yu yugang...@gmail.com wrote:
Hi,
Could a gatekeeper please help review the fix for
bug949(https://bugs.open64.net/show_bug.cgi?id=949)?
the cutdown bugcase snippet (data definition ignored) below:
if (is_send) {
a=
Looks good to me.
Sun
On Tue, Feb 7, 2012 at 9:02 AM, Ye, Mei mei...@amd.com wrote:
Attached is a fix for Bug 947. It makes sure constants with different
values are not considered the same.
The fix is taken from a patch that will be merged to the trunk but is
currently delayed due to merge
I am hoping Mike could give his feedback. If you wait another day and
no one else have any objection, please go ahead
Sun
On Thu, Jan 19, 2012 at 10:28 AM, David Coakley dcoak...@gmail.com wrote:
Thanks to Doug Gilmore for testing the patch and reporting a bug.
Following is a revised patch... I
Looks like this fix is generic and no need for #ifdef, don't you think?
sun
On Tue, Jan 17, 2012 at 5:52 PM, Rao, Shivarama shivarama@amd.com wrote:
Hi,
Could a gate keeper please review the attached patch to fix bug #944.
This fix solves a problem in debugging the open64 generated
I am ok with the change
Sun
On Mon, Jan 16, 2012 at 4:48 PM, Gang Yu yugang...@gmail.com wrote:
Hi,
Could a gatekeeper please help review the following bug?
Bug case:
typedef signed char int8_t;
typedef int int32_t;
typedef long int int64_t;
typedef unsigned long int uint64_t;
struct
there are more copyprops in the build.
Regards
Gang
On Sat, Jan 7, 2012 at 9:26 PM, Sun Chan sun.c...@gmail.com wrote:
copy prop is not always a win. I'd like to see some performance
testing. If possible, compile time testing. it is known to cause
longer compile time also (it is basically a n
upstream.
-Mei
-Original Message-
From: Sun Chan [mailto:sun.c...@gmail.com]
Sent: Friday, January 06, 2012 9:55 PM
To: Gang Yu
Cc: open64-devel
Subject: Re: [Open64-devel] Review request for fix bug787[WOPT]
this fix looks better. i am still a bit worry about regressions
I wonder what the behavior at O0 for this bug?
Sun
On Tue, Jan 10, 2012 at 8:28 AM, Sun Chan sun.c...@gmail.com wrote:
thx for pointing this out, it could cause problem for automatic bug triaging.
Sun
On Tue, Jan 10, 2012 at 1:34 AM, Ye, Mei mei...@amd.com wrote:
I don't have objection
introduces more copy-props in the code. so, personally I think
if it will not introduce performance regression.
We test the whole kernel build, besides fix bug787, it does not introduce
new failures.
Regards
Gang
On Sat, Jan 7, 2012 at 1:54 PM, Sun Chan sun.c...@gmail.com wrote:
this fix
this fix looks better. i am still a bit worry about regressions
(performance). Have you checked perf regression with this change?
Sun
On Sat, Jan 7, 2012 at 1:36 PM, Gang Yu yugang...@gmail.com wrote:
Hi,
I have a new fix for the bug787, the cut-down case from Rao(thanks) is as
follows:
or make workaround.
Regards
Gang
On Sat, Dec 31, 2011 at 10:42 AM, Sun Chan sun.c...@gmail.com
wrote:
Let me try to understand. You are asking for opinions on whether
ope64
should ignore the VLA problem until there is further documentation
and/or evidence
mail. And is only a draft version patch, which is not intended for SVN
submit currently. It is not in Open64 trunck yet.
Ling Kun
On Tue, Jan 3, 2012 at 6:34 PM, Sun Chan sun.c...@gmail.com wrote:
when did this checkin happened? Did that gone through code review and
checkin review permission
learn from the seniors and then we
can go ahead or make workaround.
Regards
Gang
On Sat, Dec 31, 2011 at 10:42 AM, Sun Chan sun.c...@gmail.com wrote:
Let me try to understand. You are asking for opinions on whether ope64
should ignore the VLA problem until there is further documentation
Let me try to understand. You are asking for opinions on whether ope64
should ignore the VLA problem until there is further documentation
and/or evidence of more VLA usage? Until then, workaround that by
changing kernel source?
Sun
On Sat, Dec 31, 2011 at 10:36 AM, Gang Yu yugang...@gmail.com
/22 Sun Chan sun.c...@gmail.com:
can you go over why the second change, set_BB(null)? And remove the
mark Reset_live_stmt()?
Sun
On Thu, Dec 22, 2011 at 3:54 PM, Jian-Xin Lai laij...@gmail.com wrote:
Hi,
Here is a smaller case for bug #897 and a new patch based on Gang's
current work. Could
,
not in HSSA. It's different problem.
2011/12/23 Sun Chan sun.c...@gmail.com:
I am still confused. You said you added this line when we hit a
bug..., which line? I also recall Fred has issue with you folks
adding an extra rename pass.
My question, that you have not address, is why add
(marked to dead at the beginning of
DCE).
2011/12/23 Sun Chan sun.c...@gmail.com:
Asking the third time, why remove Reset_live_stmt() and add Set_bb(null)?
Sun
On Fri, Dec 23, 2011 at 2:29 PM, Jian-Xin Lai laij...@gmail.com wrote:
The line is this one:
stmt-Reset_live_stmt(); // WHIRL SSA
you have yet to learn how to trace wopt.
-tt25:0xy where y is the bit for the corresponding phase
Sun
On Mon, Dec 19, 2011 at 10:46 AM, Gang Yu yugang...@gmail.com wrote:
Since effort has been made on the original fix and the bug-case is not
that big to affect the analyse , I will
Pls send more info for me to adequately review this fix.
Why do you suggest this fix. What is the problem with the assertion.
If you do that at -O0, what would happen?
Sun
On Sat, Dec 17, 2011 at 12:52 AM, Gang Yu yugang...@gmail.com wrote:
Hi,
Could a gatekeeper please help review the fix
I highly doubt you have the right fix. OTOH, I can't follow your
explaination either. Can you further cut down the example? Also, try to use
something less confusing in names because it gets mixed up with versioning
of stmt, symbol etc.
Once you have a minimum case, we can look at some trace first
Also, I don't believe we ever designed WOPT to deal with ASM statements. To
teach various phase to optimize asm stmt in wopt is not the goal.
Sun
On Sat, Dec 17, 2011 at 5:23 PM, Sun Chan sun.c...@gmail.com wrote:
if at O0, gcc optimized it, why is it the case different at O2?
Sun
On Sat
?
Regards
Gang
On Sat, Dec 17, 2011 at 5:22 PM, Sun Chan sun.c...@gmail.com wrote:
I highly doubt you have the right fix. OTOH, I can't follow your
explaination either. Can you further cut down the example? Also, try to use
something less confusing in names because it gets mixed up
wopt do not deal with ASM stmts
Sun
On Sat, Dec 17, 2011 at 5:26 PM, Gang Yu yugang...@gmail.com wrote:
Goal of this fix is not to handle ASM_INPUT, rather the condition simplify.
Regards
Gang
On Sat, Dec 17, 2011 at 5:24 PM, Sun Chan sun.c...@gmail.com wrote:
Also, I don't believe we
other than knowing what symbol it uses/def to get the ud correct
On Sat, Dec 17, 2011 at 5:32 PM, Sun Chan sun.c...@gmail.com wrote:
wopt do not deal with ASM stmts
Sun
On Sat, Dec 17, 2011 at 5:26 PM, Gang Yu yugang...@gmail.com wrote:
Goal of this fix is not to handle ASM_INPUT, rather
?
Regards
Gang
On Sat, Dec 17, 2011 at 5:28 PM, Sun Chan sun.c...@gmail.com wrote:
running correct means nothing to me. you are fixing the optimizer
trace of dce and htable
On Sat, Dec 17, 2011 at 5:23 PM, Gang Yu yugang...@gmail.com wrote:
I can confirm this is the right fix. I have tested
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
looks good to me.
Sun
On Fri, Dec 16, 2011 at 7:48 PM, Rao, Shivarama shivarama@amd.comwrote:
Hi,
** **
Could a gatekeeper please review the attached patch for Bug 938?
** **
https://bugs.open64.net/show_bug.cgi?id=938
** **
The realloc statement is
looks good to me
Sun
On Fri, Dec 16, 2011 at 8:08 PM, Rao, Shivarama shivarama@amd.comwrote:
Hi,
** **
Could a gatekeeper please review the attached patch for bug#939.
https://bugs.open64.net/show_bug.cgi?id=939
** **
In function
)) {
- 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
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
On Wed, Dec 14, 2011 at 12:34 PM, Gang Yu yugang...@gmail.com wrote:
Hi,
Would a gatekeeper
functionality at O0.
This is inspired by Fred Chow and Previously Sun Chan and Suneel
Jain's
comment on bug588.
My recommendation would be to do this kind of dead code
elimination at -O0 in Open64. That will provide greater compatibility
with gcc.
- Suneel
can you do an experiment
:* Gautam Chakrabarti [mailto:gautam.c...@yahoo.com]
*Sent:* Wednesday, December 07, 2011 9:19 AM
*To:* Gang Yu; Sun Chan
*Cc:* open64-devel
*Subject:* Re: [Open64-devel] Review request for fix bug798(O0 does not
do dce)[WOPT, infrastructure]
** **
Thanks for the answers.
I
I thought whether CVT is needed is decided with the table (I forgot exactly
where that is now). This is a machine dependent operation (zero or sign
extended when loaded from memory). E.g. IA is zero extended, Mips is sign
extended. Or am I in the wrong context?
Sun
On Tue, Nov 29, 2011 at 4:29
U4I4CVT u=1 cr18 isop_flags:0x0 flags:0x0 b=-1
the input is still:
I4INTCONST 1 (0x1)
I4I4LDID 0 st 20 T4,.predef_I4,4
I4SHL
I4INTCONST -1 (0x)
I4ADD
U4I4CVT
Regards
Gang
On Mon, Nov 28, 2011 at 10:40 AM, Sun Chan sun.c...@gmail.com wrote:
Sorry
your example should infinite loop. Pls double check before we further
discuss this
Sun
On Tue, Nov 29, 2011 at 8:41 AM, Yiran Wang yiran.w...@gmail.com wrote:
Hi All,
Could a gatekeeper review this patch?
The test case is as following, and the bug is triggered, when compiling it
with -O2.
be rightly mapped to:
LDC I8 -2147483649 u=1 cr17 flags:0x0 b=-1
U4I4CVT u=1 cr18 isop_flags:0x0 flags:0x0 b=-1
Regards
Gang
On Mon, Nov 28, 2011 at 8:22 PM, Sun Chan sun.c...@gmail.com wrote:
without your change, what is the output of this function for the same
input expr?
Sun
On Mon, Nov
I said, send me the entire expr (you just sent const and cvtl)
I want to know why const became I8 where the input is I4
On Tue, Nov 29, 2011 at 10:49 AM, Gang Yu yugang...@gmail.com wrote:
On Mon, Nov 28, 2011 at 10:40 AM, Sun Chan sun.c...@gmail.com wrote:
Sorry, pls send the corresponding
not exit, but the
loop is not entered at the very beginning, as the initial test would fail.
Regards,
Yiran
On Mon, Nov 28, 2011 at 6:15 PM, Sun Chan sun.c...@gmail.com wrote:
your example should infinite loop. Pls double check before we further
discuss this
Sun
On Tue, Nov 29, 2011 at 8:41
, 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 T4,.predef_I4,4
I4SHL
I4INTCONST -1
) == 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
looks good to me
Sun
On Sat, Nov 26, 2011 at 7:33 PM, Gang Yu yugang...@gmail.com wrote:
Hi,
Could a gatekeeper please help revie the fix for bug911
https://bugs.open64.net/show_bug.cgi?id=911?
A cutted down bug case below:
union flexcop_ibi_value {
struct {
u32 unused : 2;
u32
looks good to me.
Please add a space after //
Personally, I prefer if you add comment instead of referring to bug number.
This is not representative of gatekeepers though
Sun
On Thu, Nov 24, 2011 at 10:21 PM, Gang Yu yugang...@gmail.com wrote:
Hi,
Could a gatekeeper please help review the
?
** **
Doug
** **
*From:* Gilmore, Doug [mailto:doug.gilm...@amd.com]
*Sent:* Wednesday, November 09, 2011 2:59 PM
*To:* Sun Chan
*Cc:* open64-devel@lists.sourceforge.net
*Subject:* Re: [Open64-devel] FW: CG minor cleanup review request
** **
** **
** **
*From:* Sun Chan
, ia64, and loongson have a zero register,
while NVISA, SL, x8664, and ppc32 do not.
** **
Could a gatekeeper review this change when they have the chance?
** **
Thanks,
** **
Doug
** **
*From:* Sun Chan [mailto:sun.c...@gmail.com]
*Sent:* Monday, November 21, 2011
On Mon, Nov 21, 2011 at 7:50 AM, Sun Chan sun.c...@gmail.com wrote:
it's not clear what you meant by 'non-callable. please educate me.
your change probably match the gcc behavior, but it's not clear it will
actually accomplish what you want as DFE behavior. I don't believe
O0/1/2/3 does
isn't that a template? Why not a template?
Sun
On Thu, Nov 17, 2011 at 3:03 PM, Jian-Xin Lai laij...@gmail.com wrote:
It's better to change IPA_CG_ST_st_idx to a inline function.
2011/11/11 Yulei Sui rocky...@gmail.com:
Hello,
There is an mapping alias tag bug when Creating
I am fine with this (although I suspect the use of strstr on %P may be not
covering some error situations)
Sun
On Mon, Nov 14, 2011 at 8:35 PM, Gang Yu yugang...@gmail.com wrote:
Hi,
Could a gatekeeper please help review the fix for bug597, constraint
p not implemented assertion? Thanks
Or let CGTARG_Is_Right_Shift_Op() return false for X86 at where it is
defined
On Thu, Nov 10, 2011 at 4:34 AM, Gilmore, Doug doug.gilm...@amd.com wrote:
I see that another Post-5.0 change has been committed to the trunk.
** **
Could someone review this change when they have a
paths.
-Mei
From: Sun Chan [mailto:sun.c...@gmail.com]
Sent: Tuesday, October 18, 2011 12:57 AM
To: open64-devel@lists.sourceforge.net
Subject: Re: [Open64-devel] r3764 - trunk/osprey/be/opt
This is strange. Must be a regression from elsewhere. I am sure the identity
stmt had been
1 - 100 of 294 matches
Mail list logo
