A volatile variable cannot be involved in much optimization without
affecting correctness. E.g. a CSE involving a volatile variable deletes
a use, which is wrong. The defs and uses of a volatile variable must be
preserved at their original places. Since SSA is for performing
optimizations, i
ied "x" or "z", and
strength reduction works fine.
Best Regards,
Yiran
On Tue, Jul 2, 2013 at 5:29 AM, Fred Chow <mailto:frdc...@gmail.com>> wrote:
Hi Yiran,
The reason is because PRE is not applied to the increment amount
of an IV update statement. In your e
Hi Yiran,
The reason is because PRE is not applied to the increment amount of an
IV update statement. In your example,
x += N*N << 3;
is an IV update statement. If PRE is applied, the rhs of the IV update
statement may be transformed so that the statement is no longer an IV
update stateme
On 09/07/2011 07:51 AM, Gang wrote:
On 09/07/2011 10:59 AM, Jian-Xin Lai wrote:
3. In osprey/common/com/opcode_gen_core.h, since OPR_ZDLBR is
added for all targets, why not move it out of the #ifdef and
change the value for the later OPRs?
This is mainly for mai
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 <mailto:frdc...@gmail.com>> wrote:
Hi Shi,
Your change to force other aliased chi nodes to live in
DSE::Set_Reqruied
y intuition is that
making the default vsym non-live (when in fact it is live) will cause
other bugs.
Fred
Regards
Shi Hui
On Tue, Jul 5, 2011 at 5:16 PM, Fred Chow <mailto:frdc...@gmail.com>> wrote:
Hi Shi,
Your fix by calling CODEMAP rename is OK in its own right. But
blem.
Regards
Shi Hui
On Mon, Jul 4, 2011 at 9:26 PM, Fred Chow <mailto:frdc...@gmail.com>> wrote:
Doing renaming is quite compile-time expensive, because it is like
running the SSA construction algorithm. The problem your
mentioned would not have occurred if sym2v3 has
Doing renaming is quite compile-time expensive, because it is like
running the SSA construction algorithm. The problem your mentioned
would not have occurred if sym2v3 has not been propagated down to
STMT3. I don't recall we were doing copy propagation for chi operands.
The overlapped live r
be
> extended. In other words, the new operation is intended to represent not one,
> but a set of blend operations.
>
> Thanks.
> Pallavi
>
> -Original Message-
> From: Fred Chow [mailto:frdc...@gmail.com]
> Sent: Wednesday, June 15, 2011 2:56 PM
> To: M
pon
> value of the mask in kid2 as shown below:
> if (msb(kid2[n]) == 0)
> then
> result[n] = kid0[n]
> else
> result[n] = kid1[n]
>
> where msb(x) represents the most significant bit of x.
> and foo[n] represent the n-th byte of foo.
>
> -Pallavi
>
Instead of look at source code and guessing at the definition of
OPR_BLEND, is there some document where we can describe the definition
of new WHIRL opcodes?
Fred
On 06/14/2011 02:51 PM, Sun Chan wrote:
> This is a WHIRL change, Fred, can you look at the change (at least the
> new OPR_BLEND) to
ts.
Fred
On 06/02/2011 12:53 PM, Ye, Mei wrote:
Attached.
*From:*Ye, Mei
*Sent:* Thursday, June 02, 2011 12:52 PM
*To:* 'Fred Chow'
*Cc:* open64-devel@lists.sourceforge.net
*Subject:* RE: [Open64-devel] code review - fix for Bug #778
Hi Fred
The overflow situation is rare for 64-bit a
is the stride of memory
access."end" is the new loop upper-bound, which is:
"beginning_memory_address + const2 * upperbound_of_original_IV".
So "end -- const2" will never be below 0.
Sorry that my explanation of "end" in my 1^st Email may be a bit
confusing.
-M
eates an
overhead. But it is needed to preserve correctness.
-Mei
*From:*Fred Chow [mailto:frdc...@gmail.com]
*Sent:* Friday, May 27, 2011 7:42 PM
*To:* open64-devel@lists.sourceforge.net
*Subject:* Re: [Open64-devel] code review - fix for Bug #778
Mei,
The problem you described is the n
Mei,
The problem you described is the notarious wraparound issue when
performing LFTR (that's why we provide the -OPT:wrap_around_unsafe_op"
flag to help diagnose such problems when optimization changes a
program's behavior). But your claim that your change makes this problem
"less likely" t
;
On Fri, Apr 29, 2011 at 6:50 PM, Fred Chow <mailto:frdc...@gmail.com>> wrote:
Hi Hui,
This version will not apply assertion if (((mINT32)TCON_v0(*tc))
>= 0), so will only have half as much assertion coverage as what
the original code intended.
Fred
On 04/2
Hi Hui,
This version will not apply assertion if (((mINT32)TCON_v0(*tc)) >= 0),
so will only have half as much assertion coverage 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 i
-592,6 +595,7 @@
_symbols_to_revise->Union1D(idx);
AUX_STAB_ENTRY *aux = _opt_stab->Aux_stab_entry(idx);
aux->Points_to()->Set_expr_kind(EXPR_IS_ADDR);
+ aux->Points_to()->Set_ofst_kind(OFST_IS_FIXED);
aux->Points_to()->Set_na
This same fix was in the PathScale 3.2 beta source. But there are 4
places in that file that need this addition. I see you only have
covered two places.
Fred
On 04/18/2011 04:32 AM, Jian-Xin Lai wrote:
Hi,
Can a gate keeper review the patch to remove unnecessary CHIs
introduced by Lda-Ind
Sun,
If you can recall the various responses to my comments in our discussion
on this topic in our OSG meeting of March 24th, I would come to the same
conclusion as Christopher.
Fred
On 03/31/2011 04:26 PM, Sun Chan wrote:
> Christopher,
> This is misleading at the very least. OSG is in the pr
Hi Jian-Xin,
This is a good fix. Please check it in. Thanks.
Fred
On 03/05/2011 08:37 PM, Jian-Xin Lai wrote:
Hi,
Could a gate keeper review the patch to bug 740? Thank you very much.
This bug occurs in COMP_UNIT::Lower_to_extract_compose().
Before this phase, the IR in BB6 is:
(not l
0,PEXTRW> 0
I8I4LDID 0 <2,2,i> T<9,.predef_U8,8>
U8I8CVT
U8INTCONST 2 (0x2)
U8MPY
U8U8LDID 0 <2,1,baseAddr> T<53,anon_ptr.,8>
U8ADD
I2ISTORE 0 T<53,anon_ptr.,8> {line: 1/4}
It looks like this fix is much better than the previous one. C
It looks good. Go ahead and check it in.
Fred
On 03/04/2011 02:15 PM, Feng Zhou wrote:
> Thank you very much for the comment. I have updated the fix as
> attached. Let me know if you have any problems.
>
> -- Feng
>
>
>
> On Thu, Mar 3, 2011 at 11:20 PM, Fred
The I2INTRINSIC_OP can actually be I4INTRINSIC_OP without causing any
other problem. In general, rtype should be a type corresponding to a
register. Since there is no register of size I2, I'm not comfortable
with rtype being I2.
In the WHIRL document under INTRINSIC_OP, there is this commen
w_cr, because looks like to me that anytime we need to modify cr, we
> copy it to new_cr and then update new_cr and rehash it.
>
> -- Feng
>
>
>
> On Tue, Mar 1, 2011 at 11:37 PM, Fred Chow wrote:
>> Hi Feng,
>>
>> You need to also set need_rehash to TRUE
>
>
> On Wed, Feb 16, 2011 at 4:45 PM, Feng Zhou wrote:
>> Thanks for the suggestion. I will update the fix and send it for code
>> review again when it is ready.
>>
>> --Feng
>>
>>
>>
>> On Tue, Feb 15, 2011 at 10:58 PM, Fred Chow wrot
preventing the good optimization) is to
also fix the size of the operands by inserting U4U8CVT for both operands.
Fred Chow
On 02/15/2011 09:31 AM, Feng Zhou wrote:
Hello, all
Can gatekeeper review the patch to bug #544 for me please? Thank you.
Bug #544 is caused by bitwise dead code elimniation
It depends on whether the target machine has 16-bit register operands.
Strictly speaking, I2I2ILOAD means loading a 16-bit data to a 16-bit
register. I4I2ILOAD means loading from a 16-bit location and expanding
the result to make it occupy a 32-bit register, which can be translated
to one mac
We just generate the WHIRL according to what is given to us in GNU
tree/spin. So it is GNU's C front-end that has this discrepancy.
Fred
On 10/06/2010 01:34 AM, "C. Bergström" wrote:
> I'm forwarding this question..
>
> ELSE block removed to shorten the example..
> --
>
> when I have co
lobal=off:dce_branch=off:bdce=off:epre=off:ivar_pre=off:lpre=off
-IPA:dve=off:fold_cvt=off.
but it does not work, any suggestions ?
- Original Message -
*From:* eirc.lew <mailto:eirc@gmail.com>
*To:* Fred Chow <mailto:frdc...@gmail.com> ;
open64-devel@list
Just add the flags -WOPT:icopy=off:copy=off to turn off copy propagation.
Fred
On 08/17/2010 12:39 AM, eirc.lew wrote:
Hi, all
for example:
int a;
int c;
a = 5;
int b;
b += a + c;
after open64 has compiled, in the whirl it is: b += *5* + c;
but what I want is: it is still b + = *a
31 matches
Mail list logo
