RE: cmov for stores

["rajagopal, dwarak" <dwarak dot rajagopal at amd dot com>]

Can it be done in one of the two ways below?

1) tree-if-conv.c which is done before the vectorizer pass at tree
level. I believe this does some if-conversions in loops and in this
case, it fails here because "LHS is not a var decl" in
"if_convertible_modify_expr_p". 

To convert "if (g > A[k]) A[k]=g;" to cmov, can a check be done at this
place to see if there is any def to A[k] in the dominator tree and
continue with if-conversion?

2) To do this is "ifcvt.c" - I checked out how the software pipelining
is done in modulo-sched.c. I believe the Data-Dependence graph is built
for each loop. Can we do a similar thing for ifcvt.c and then use the
dominator info in "basic-block" structure to figure out if the store
could be if-converted.

 Thanks,
-Dwarak


-----Original Message-----
From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf Of
Steven Bosscher
Sent: Thursday, February 09, 2006 1:31 PM
To: gcc@gcc.gnu.org
Cc: rajagopal, dwarak
Subject: Re: cmov for stores

On Thursday 09 February 2006 20:04, rajagopal, dwarak wrote:
> The fact here is that in this case, A[k] will never trap because the
> A[k] is already been written once along the path from Entry to the
"A[k]
> = g". So it is safe to convert it to a cmov statement.

But GCC doesn't know that this memory address has already been written
to, so you don't have that information available in ifcvt.

> I'm planning to add this heuristic to the compiler

Where and how?   This may be a lot harder than you think it is.

> but I'm not sure 
> which level that information is available. Is it possible/better to do
> this in rtl level inside the ifcvt.c or do we need SSA for this
> information?

Obviously, you need this information at the RTL level (that's where the
if-conversion pass is) but computing this information on RTL is really
not feasible.  On the other hand, if you implement it on trees (ie. for
GIMPLE in SSA form) then you need to figure out some scheme to propagate
the information through the lowering process from GIMPLE to RTL.  That's
not an easy job, either.

But, I wish you luck :-)

Gr.
Steven

-----Original Message-----
From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf Of
rajagopal, dwarak
Sent: Thursday, February 09, 2006 1:05 PM
To: gcc@gcc.gnu.org
Subject: cmov for stores

int cmov(int* A ,int B ,int C ,int* D ,int* E ,int F ,int g) {
  int k,f;
  for (k = 1; k <= 1000; k++) {
    A[k] = B+C;
    g = D[k-1] + E[k-1];
    if (g > A[k])  A[k]=g; 	/* This is not converted to cmov*/
    f += g;
  }
  return f;
}

In the above code, the if-then statement is not converted to conditional
move. It fails for "noce_mem_write_may_trap_or_fault_p ()" condition in
"ifcvt.c" as it thinks that there is a chance for A[k] access to trap.
The fact here is that in this case, A[k] will never trap because the
A[k] is already been written once along the path from Entry to the "A[k]
= g". So it is safe to convert it to a cmov statement. Though there
might be two extra moves (mem to reg and vice versa) statement, it is
still better to avoid the branch especially if it is unpredictable data
like for the eg above.

I'm planning to add this heuristic to the compiler but I'm not sure
which level that information is available. Is it possible/better to do
this in rtl level inside the ifcvt.c or do we need SSA for this
information? 

Thanks,
Dwarak