On 03/23/2012 10:39 AM, Aldy Hernandez wrote:
so enter it as 2 testcases, one increasing x and one increasing y, or
better yet set it up so that this function is called twice from
simulate_main, with other_process() increasing x the first time and
increasing y the second time... or something like that.
On 03/21/12 12:54, Andrew MacLeod wrote:
On 03/21/2012 01:35 PM, Aldy Hernandez wrote:
In the test below, we cannot cache either [x] or [y] neither before
the load of flag1 nor the load of flag2. This is because the
corresponding store/release can flush a different value of x or y:
+ if (__atomic_load_n (&flag1, __ATOMIC_ACQUIRE))
+ i = x + y;
+ if (__atomic_load_n (&flag2, __ATOMIC_ACQUIRE))
+ a = 10;
+ j = x + y;
Actually, does it need to be that complicated?
can't you simply have the "other_thread" process monotonically increase
x by 1 every cycle?
then if the load is hoisted and commoned, simulate_thread_final_verify()
can simply check that if i == j, it knows that x was loaded as a common
value and reused when calculating j. with the other thread increasing x
eveyr sycle, they should never be the same value.
Hmmm, for this particular case I know CSA is commoning x + y, but what
if another combination of passes hoists only y and leaves x alone. It
would be nice to test that y isn't hoisted independently of x. Would
it not, or do you only want to test this particular behavior?