On Tue, Jun 25, 2019 at 9:49 PM Akshat Garg <xks...@gmail.com> wrote:
> On Tue, Jun 25, 2019 at 4:04 PM Ramana Radhakrishnan <
> ramana....@googlemail.com> wrote:
>
>> On Tue, Jun 25, 2019 at 11:03 AM Akshat Garg <xks...@gmail.com> wrote:
>> >
>> > As we have some working front-end code for _Dependent_ptr, What should
>> we do next? What I understand, we can start adding the library for
>> dependent_ptr and its functions for C corresponding to the ones we created
>> as C++ template library. Then, after that, we can move on to generating the
>> assembly code part.
>> >
>>
>>
>> I think the next step is figuring out how to model the Dependent
>> pointer information in the IR and figuring out what optimizations to
>> allow or not with that information. At this point , I suspect we need
>> a plan on record and have the conversation upstream on the lists.
>>
>> I think we need to put down a plan on record.
>>
>> Ramana
>
> [CCing gcc mailing list]
>
> So, shall I start looking over the pointer optimizations only and see what
> information we may be needed on the same examples in the IR itself?
>
> - Akshat
>
I have coded an example where equality comparison kills dependency from the
document P0190R4 as shown below :
1. struct rcutest rt = {1, 2, 3};
2. void thread0 ()
3. {
4. rt.a = -42;
5. rt.b = -43;
6. rt.c = -44;
7. rcu_assign_pointer(gp, &rt);
8. }
9.
10. void thread1 ()
11. {
12. int i = -1;
13. int j = -1;
14. _Dependent_ptr struct rcutest *p;
15.
16. p = rcu_dereference(gp);
17. j = p->a;
18. if (p == &rt)
19. i = p->b; /*Dependency breaking point*/
20. else if(p)
21. i = p->c;
22. assert(i<0);
23. assert(j<0);
24. }
The gimple unoptimized code produced for lines 17-24 is shown below
1. if (p_16 == &rt)
2. goto <bb 3>; [INV]
3. else
4. goto <bb 4>; [INV]
5.
6. <bb 3> :
7. i_19 = p_16->b;
8. goto <bb 6>; [INV]
9.
10. <bb 4> :
11. if (p_16 != 0B)
12. goto <bb 5>; [INV]
13. else
14. goto <bb 6>; [INV]
15.
16. <bb 5> :
17. i_18 = p_16->c;
18.
19. <bb 6> :
20. # i_7 = PHI <i_19(3), i_8(4), i_18(5)>
21. _3 = i_7 < 0;
22. _4 = (int) _3;
23. assert (_4);
24. _5 = j_17 < 0;
25. _6 = (int) _5;
26. assert (_6);
27. return;
The optimized code after -O1 is applied for the same lines is hown below :
1. if (_2 == &rt)
2. goto <bb 3>; [30.00%]
3. else
4. goto <bb 4>; [70.00%]
5.
6. <bb 3> [local count: 322122547]:
7. i_12 = rt.b;
8. goto <bb 6>; [100.00%]
9.
10. <bb 4> [local count: 751619277]:
11. if (_1 != 0)
12. goto <bb 5>; [50.00%]
13. else
14. goto <bb 6>; [50.00%]
15.
16. <bb 5> [local count: 375809638]:
17. i_11 = MEM[(dependent_ptr struct rcutest *)_2].c;
18.
19. <bb 6> [local count: 1073741824]:
20. # i_7 = PHI <i_12(3), i_11(5), -1(4)>
21. _3 = i_7 < 0;
22. _4 = (int) _3;
23. assert (_4);
24. _5 = j_10 < 0;
25. _6 = (int) _5;
26. assert (_6);
27. return;
Statement 19 in the program gets converted from i_19 = p_16->b; in line 7
in unoptimized code to i_12 = rt.b; in line 7 in optimized code which
breaks the dependency chain. We need to figure out the pass that does that
and put some handling code in there for the _dependent_ptr qualified
pointers. Passing simply -fipa-pure-const, -fguess-branch-probability or
any other option alone does not produce the optimized code that breaks the
dependency. But applying -O1, i.e., allowing all the optimizations does so.
As passes are applied in a certain order, we need to figure out upto what
passes, the code remains same and after what pass the dependency does not
holds. So, we need to check the translated code after every pass.
Does this sounds like a workable plan for ? Let me know your thoughts. If
this sounds good then, we can do this for all the optimizations that may
kill the dependencies at somepoint.
-Akshat
