ok for google branch for now. Please resubmit to trunk and backport
the trunk version if needed.
thanks,
David
On Tue, Feb 11, 2014 at 10:29 AM, Wei Mi wrote:
>>> +/* Return true if the use is defined by a gcov counter var.
>>> + It is used to check if an iv candidate is generated for
>>> +
>> +/* Return true if the use is defined by a gcov counter var.
>> + It is used to check if an iv candidate is generated for
>> + profiling. For profile generated ssa name, we should not
>> + use it as IV because gcov counter may have data-race for
>> + multithread program, it could involve
On Mon, Feb 10, 2014 at 11:48 PM, Wei Mi wrote:
> Here is the updated patch, which follow UD chain to determine whether
> iv.base is defined by __gcovx.xxx[] var. It is a lot simpler than
> adding a tree bit.
>
> regression test and previously failed benchmark in piii mode is ok.
> Other test is g
Here is the updated patch, which follow UD chain to determine whether
iv.base is defined by __gcovx.xxx[] var. It is a lot simpler than
adding a tree bit.
regression test and previously failed benchmark in piii mode is ok.
Other test is going on.
2014-02-10 Wei Mi
* tree-ssa-loop-ivop
I don't think you should add a new tree bit just for this. A simple
UD check can determine prephitmp_23, etc are abnormal ssa names:
# prephitmp_23 = PHI
PROF_edge_counter_10 = prephitmp_23 + 1;
__gcov0.foo[0] = PROF_edge_counter_10;
Note you may need to 'hack' a little to check if a stati
Hi,
I saw a bug happened in fdo-gen phase when a gcov counter related ssa
name was used as induction variable and used to calculate loop
boundary after loop cond was replaced by an expr with the ssa name. We
knew that there was data race in gcov counter in multithread program,
so the values in gco
