It sounds like no way to update the alias information. In that case, it has
to be set to NULL.
For this specific case here, only the FSA information becomes invalid, I
think, and is there any way to ignore this part only?
Regards,
Yiran
On Mon, Oct 13, 2014 at 8:11 AM, Jian-Xin Lai wrote:
> Hi,
Set_omitted()" in opt_etable.cxx and see that
> "occur->Stmt()->Iv_update()" is one reason an expression is set omitted.
>
> Fred
>
>
> On 06/26/2013 05:07 PM, Yiran Wang wrote:
>
> Hi All,
>
> This one looks somewhat similar to the last example, but
tle:
>
> for(i = 0; i< j; i++)
> {
> int t = N*N;
> x += t << 3;
> z = x + N;
> y = y + *x + *z;
> }
>
> Will the N*N be hoisted?
>
>
> 2013/6/27 Yiran Wang
>
>> Hi All,
>>
>> This one looks somewhat similar t
lt looks good for this test case. I wonder
if there is any correctness issue for some other test case, or performance
issue?
It should be noted one strength reduction transformation is done for z for
this case. Also replacing "N>>=3;" with "N*=5;" results i
compiler may find more redundancy in the loop.
-yiran
On Thu, Jul 12, 2012 at 5:04 PM, Sun Chan wrote:
> the adding of 44 was copy propagated into the loop. there used to be
> code that guards such kind of propagation inside the loop
> Sun
>
> On Fri, Jul 13, 2012 at 7:53 AM, Yi
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 Wang
> wrote:
> >> Hi Sun,
> >>
> >> Thanks for your reply.
&g
urn, which instruction is redundant?
> Sun
>
> On Fri, Jul 13, 2012 at 7:21 AM, Sun Chan 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
te:
> > hi buddy, this loop can be vectorized:
> >
> > v_init =
> > v_inc = <4d, 4d, 4d, 4d>
> >
> > the statement can be vect into:
> > a[0:3] = v_init;
> > v_init += v_inc;
> >
> >
> >
> > On 07/12
Hi All,
It looks like strength reduction is not optimal for the following example?
7 instructions per iteration is used, but 4 (or 5 without LFTR) are
necessary.
Best Regards,
Yiran Wang
bash-4.0$ cat x.c
int foo(int x, int b, int *__restrict a)
{
int i;
int c,d ;
c = b*60;
d = c+44
I think we may add some detection of this pitfall, as it is a bit common,
i.e. to have a brief look if it is the top-level directory of open64 source
in "configure".
Best Regards,
Yiran
On Thu, Dec 8, 2011 at 9:27 PM, Wu Yongchong wrote:
> You should not configure and make open64 in the top dir
not supposed to be an "optimization" phase. For the given
> phase, VHO might be a good place to eliminate the unreachable case
> when lowering the switch.
>
> 2011/12/7 Yiran Wang :
> > I am not a gatekeeper, but excuse me, I wonder if why not do such kind of
> > stuff
I am not a gatekeeper, but excuse me, I wonder if why not do such kind of
stuff with WGEN.
Regards,
Yiran
On Tue, Dec 6, 2011 at 6:53 PM, Gang Yu wrote:
> Hi,
>
>Could a gatekeeper please help review the fix for bug798(
> http://bugs.open64.net/show_bug.cgi?id=798)?
>
> This is a bug for a
long time. Anyway you can make that work?
> Sun
>
> On Tue, Nov 29, 2011 at 12:37 PM, Yiran Wang wrote:
>
>> Em, I think you are saying that once entered, it would not exit, but the
>> loop is not entered at the very beginning, as the initial test would fail.
>>
>> Reg
iscuss this
> Sun
>
> On Tue, Nov 29, 2011 at 8:41 AM, Yiran Wang 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.
>>
>> #in
Hi All,
Could a gatekeeper review this patch?
The test case is as following, and the bug is triggered, when compiling it
with -O2.
#include
struct x{
int y;
int z;
};
int foo()
{
struct x xyz,abc;
int i;
memset(&xyz,0,sizeof(xyz));
i = 1;
while( i < 0 )
{
abc.y += xyz.z;
Hi Gang,
A silly question, is the ZDL loop supposed to have at least one iteration ?
Best Regards,
Yiran
On Sat, Jul 9, 2011 at 6:45 AM, Gang Yu wrote:
>
> On Sat, Jul 9, 2011 at 12:40 AM, Ding-Kai Chen wrote:
>
>>
>> Have you looked into binding to ZDL inside CG instead of at WHIRL level?
>>
I think it is good to improve the message, as we allow all 1s and all 0s.
Regards,
yiran
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 0xf
The SGI document on WHIRL also mentioned this OPR.
yiran
On Thu, Apr 14, 2011 at 2:31 PM, Yiran Wang wrote:
> I do not know. But, it seems like the operator is not new at all, but
> somebody (probably PathScale?) use it in some different way here.
> OPR_NEG = 87,
> OP
= 111,
OPR_STBITS = 112,
The above is a fragment from opcode_gen_core.h.
Best Regards,
yiran
On Thu, Apr 14, 2011 at 2:23 PM, Sun Chan wrote:
> my question is, who added this operator? This is a change in WHIRL
> Sun
>
> On Thu, Apr 14, 2011 at 2:20 PM, Yiran Wang wrote:
>&g
Hi,
could a gatekeeper please review this patch?
This change is to deal with the OPR_PAREN nodes in this subroutine,
which is inserted by simd-mark-code phase.
Best Regards,
yiran
Index: osprey/be/lno/scalar_expand.cxx
===
--- ospre
Hi,
could a gatekeeper review this patch?
Such a combination is abandoned for load-execution as the ld_op is a
load up higher part of a SSE register, while the alu_op is doing
conversion on the lower part (implicitly).
Best Regards,
Yiran
Index: osprey/be/cg/x8664/ebo_special.cxx
==
Hi All,
Could a gatekeeper please review this patch?
It is about to find out constant branches. If the compare instruction
has an operator in memory, it is not possible to evaluate it at
compile time.
Best Regards,
Yiran
Index: osprey/be/cg/cflow.cxx
LinkedIn
Yiran Wang requested to add you as a connection on LinkedIn:
--
Bin,
I'd like to add you to my professional network on LinkedIn.
- Yiran
Accept invitation from Yiran Wang
http://www.linkedin.com/e/bqhq7t-gmf1gx
Hi,
Could a gatekeeper please review this patch?
When the eh-range get flattened, this specific eh-range generated is
part of the original range "j", rather than "i".
Best Regards,
yiran
Index: osprey/be/cg/eh_region.cxx
===
--- os
MTYPE_C8 == ty && Opt_Level != 0)
{
/* complex const converted to real const */
if (k0const && SIMPNODE_rtype(k0) == ty)
Best Regards,
yiran
------ Forwarded message --
From: Yiran Wang
Date: Wed, Mar 30, 2011 at 1:16 PM
Subject: code review for fix of
Hi,
Could a gatekeeper please review this patch?
The command line: openf90 -m32 -march=athlon x.f -c -keep -O0
The source file:
program test
real*8 :: ms
complex*16 :: direct, crossed
ms = 2.*(direct+crossed)
end
The output :
### Assertion failure at l
at 2:17 PM, Yiran Wang wrote:
> Hi Sun,
>
> I investigate the bug a little bit, and the findings are:
>
> 0. Usually, -pic and -pie is linker option, while -fpic and -fpie is option
> for BE (for opencc). And -pie and -pic have the same effect, and -fpie and
> -fpic have the sa
Hi Sun,
I investigate the bug a little bit, and the findings are:
0. Usually, -pic and -pie is linker option, while -fpic and -fpie is option
for BE (for opencc). And -pie and -pic have the same effect, and -fpie and
-fpic have the same effect, for open64 (or it would check if an executable
is be
Hi,
Could a gatekeeper please review this patch?
The issue is that when r->high is a const, the call to method cr() would
trigger an assertion.
As the fix, for such case, it is different from this_vr->High.
Best Regards,
yiran
Index: osprey/be/opt/opt_lmv_helper.cxx
luckily, it seems like there is no reference at all
Regards,
yiran
On Mon, Nov 1, 2010 at 2:31 PM, Hucheng Zhou wrote:
> opt_etable.h
>
> *voidReset_no_lftr(void) { _flags &= EWF_NO_LFTR; }*
> *
> *
> *which should be:*
> *
> *
> *voidReset_no_lftr(void) { _flags &= ~EWF
Agree, when the value is unwanted explicitly, the generate WHIRL is just the
same, i.e.
#include
#include
int main()
{
int i = rand();
printf("i = %i\n", i);
if (i)
printf("i = %i\n", i);
return 0;
}
On Thu, Oct 7, 2010 at 1:02 PM, Handong Ye wrote:
> A wild guess. The code needs
-- Forwarded message --
From: Yiran Wang
Date: Fri, Sep 10, 2010 at 4:25 PM
Subject: Re: [Open64-devel] code review for fix of bug 633
To: Sun Chan
This chunk is where the variable ret_mtype is first defined. It looks like
if the result is needed, it is set in someway, else it
Hi All,
Could some gatekeeper please review this change?
The issue is as following:
For a goto to outer block, the cleanup of local objects are needed. While, for
call of destructor for each of them, the call is nested in a eh-region, as the
destructor itself may throw exceptions. As we can see,
:
> why is F8 the default, but not others?
> Sun
>
> On Sat, Sep 11, 2010 at 6:08 AM, Yiran Wang wrote:
> > Hi Sun,
> > Sure.
> > The situation is as following.
> > There is implementation of the intrinsic "sqrt", for a number of types,
> such
>
not enough for me to tell why F8 is the
> right type, but not, say, F4, or V8
> Sun
>
> On Sat, Sep 11, 2010 at 2:58 AM, Yiran Wang wrote:
> > Hi All,
> > Could a gatekeeper please review it?
> > Simply, the ret_mtype should be reset automatically, if it is
Hi All,
Could a gatekeeper please review it?
Simply, the ret_mtype should be reset automatically, if it is void. This is
already done for a number of other intrinsics.
The bug is triggered when the combination of > and ?: operator is used, as
the result type is not set by parent of the intrinsic
It cannot work. Complex lowering would lower complex-types C8 to V16C8 or
F8.
There can be too solutions
1. C8 and V16C8 are complex types, while C8 is machine-independent-complex
types, which is lowered by complex lowering (to modify complex lowering a
bit.).
2. V16C8 are defined as machine-imp
37 matches
Mail list logo
