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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
