Re: Can LTO minor version be updated in backward compatible way ?

[Martin Liška]

On 7/22/19 4:31 PM, Jeff Law wrote:
> On 7/22/19 8:25 AM, Martin Liška wrote:
>> On 7/17/19 8:10 PM, Jeff Law wrote:
>>> On 7/17/19 11:29 AM, Andi Kleen wrote:
 Romain Geissler  writes:
>
> I have no idea of the LTO format and if indeed it can easily be updated
> in a backward compatible way. But I would say it would be nice if it
> could, and would allow adoption for projects spread on many teams
> depending on each others and unable to re-build everything at each
> toolchain update.

 Right now any change to an compiler option breaks the LTO format
 in subtle ways. In fact even the minor changes that are currently
 done are not frequent enough to catch all such cases.

 So it's unlikely to really work.
>>> Right and stable LTO bytecode really isn't on the radar at this time.
>>>
>>> IMHO it's more important right now to start pushing LTO into the
>>> mainstream for the binaries shipped by the vendors (and stripping the
>>> LTO bits out of any static libraries/.o's shipped by the vendors).
>>>
>>>
>>> SuSE's announcement today is quite ironic. 
>>
>> Why and what is ironic about it?
> Sorry, you'd have to have internal context -- we'd been discussing it
> within the Red Hat team for Fedora 32 the previous day.  One of the
> questions that came up was whether or not any other major distributor
> was shipping with LTO enabled :-)

According to what I know, OpenMandriva should be using LTO:
https://www.openmandriva.org/en/news/article/openmandriva-lx-4-0-rc-released
but the package building machinery is closed, so I can't confirm that.

One another example is Gentoo:
https://github.com/InBetweenNames/gentooLTO
but it's up to users preferences.

So that I consider openSUSE Tumbleweed as a first one :P

Martin


> 
> 
> Jeff
> 

Re: Can LTO minor version be updated in backward compatible way ?

[Jeff Law]

On 7/23/19 2:49 AM, Martin Liška wrote:
> On 7/22/19 4:31 PM, Jeff Law wrote:
>> On 7/22/19 8:25 AM, Martin Liška wrote:
>>> On 7/17/19 8:10 PM, Jeff Law wrote:
 On 7/17/19 11:29 AM, Andi Kleen wrote:
> Romain Geissler  writes:
>>
>> I have no idea of the LTO format and if indeed it can easily be updated
>> in a backward compatible way. But I would say it would be nice if it
>> could, and would allow adoption for projects spread on many teams
>> depending on each others and unable to re-build everything at each
>> toolchain update.
>
> Right now any change to an compiler option breaks the LTO format
> in subtle ways. In fact even the minor changes that are currently
> done are not frequent enough to catch all such cases.
>
> So it's unlikely to really work.
 Right and stable LTO bytecode really isn't on the radar at this time.

 IMHO it's more important right now to start pushing LTO into the
 mainstream for the binaries shipped by the vendors (and stripping the
 LTO bits out of any static libraries/.o's shipped by the vendors).


 SuSE's announcement today is quite ironic. 
>>>
>>> Why and what is ironic about it?
>> Sorry, you'd have to have internal context -- we'd been discussing it
>> within the Red Hat team for Fedora 32 the previous day.  One of the
>> questions that came up was whether or not any other major distributor
>> was shipping with LTO enabled :-)
> 
> According to what I know, OpenMandriva should be using LTO:
> https://www.openmandriva.org/en/news/article/openmandriva-lx-4-0-rc-released
> but the package building machinery is closed, so I can't confirm that.
> 
> One another example is Gentoo:
> https://github.com/InBetweenNames/gentooLTO
> but it's up to users preferences.>
> So that I consider openSUSE Tumbleweed as a first one :P
As do I.

Jeff

Re: RFC: Deprecate libstdc++ Policy-Based Data Structures

[Jonathan Wakely]

Sorry for the late reply that wasn't "tomorrow".

On Tue, 9 Jul 2019 at 23:40, Alexander Kulkov wrote:
>
> Hi there! I hope, this message will go to where it's expected to go, since
> I'm not really familiar with e-mail threads.
>
> I was the one who brought https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81806
> issue about sub-optimal implementation of split function in pbds. The
> reason why I did so is clearly described on this comment:
> https://codeforces.com/blog/entry/10355?#comment-157883
>
> So, a bit of story and context. Five years ago at codeforces.com
> (competitive programming website) someone eventually pointed out that there
> is order-statistics tree in SGI library. It turned out to be very useful in
> competitions since it is quite common type of queries to count number of
> elements less than k in set and unfortunately regular std::set doesn't
> provide such possibility although it would be extremely useful in
> competitions.
>
> I made two posts about pbds on codeforces to introduce them to community:
> https://codeforces.com/blog/entry/11080 and
> https://codeforces.com/blog/entry/13279. First one introduces structures in
> general and second one describes how to modify them so they support custom
> queries. Second one was not quite as popular, perhaps because it's not much
> easier to comprehend and remember concept than simply write something like
> cartesian tree on live contest. But the first one is pretty much alive,
> most recent comment was only 8 days ago.
>
> There was also another post (https://codeforces.com/blog/entry/60737)
> considering hash_map from pb_ds as a replacement for unordered_map since
> hash_map clearly outperform unordered_map. This one is also quite popular
> and well-known in competitive programming community.
>
> So speaking about "Do you actually use these containers?" I would say that
> I often use tree_order_statistics_node_update in competitions, and in
> general specifically tree_order_statistics_node_update and hash_map are
> pretty popular in competitive programming community.
>
> Deprecating policy based data structures will deal much pain to some
> competitors because problems in which it's possible to use pbds instead of
> custom balanced binary trees occur quite often and so now we'll have to
> implement bbst instead of using something out of the box.
>
> Not sure if you would consider this usage case as something "serious", but
> well, I was asked, so I answered.

Thanks for responding!

I don't really care about this use case, sorry. If the programming
competition community were providing fixes or improvements for this
code I might be more inclined to keep supported it, but it seems like
we're just carrying around a huge chunk of code because it saves
people some time in some competitions. Presumably the competition code
is not reused, so there's no backwards compatibility issue here
either.

Re: RFC: Deprecate libstdc++ Policy-Based Data Structures

[Alexander Kulkov]

Sounds fair to me. Well, I personally might be interested in providing
fixes and improvements for the code. I might even try to find some other
people in community to contribute.

PBDS is very well-thought library which I admired since the moment I saw
it, and the possibility that it may completely go to waste kind of
disappoints me, so I might put considerable effort to save it if that's
possible. The major issue, though, is that I don't really know even how to
start since I'm completely new to libstdc++ and have little experience with
such huge projects. Any help and/or advice here in how I may contribute
would be much appreciated.

вт, 23 июл. 2019 г. в 19:21, Jonathan Wakely :

> Sorry for the late reply that wasn't "tomorrow".
>
> On Tue, 9 Jul 2019 at 23:40, Alexander Kulkov wrote:
> >
> > Hi there! I hope, this message will go to where it's expected to go,
> since
> > I'm not really familiar with e-mail threads.
> >
> > I was the one who brought
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81806
> > issue about sub-optimal implementation of split function in pbds. The
> > reason why I did so is clearly described on this comment:
> > https://codeforces.com/blog/entry/10355?#comment-157883
> >
> > So, a bit of story and context. Five years ago at codeforces.com
> > (competitive programming website) someone eventually pointed out that
> there
> > is order-statistics tree in SGI library. It turned out to be very useful
> in
> > competitions since it is quite common type of queries to count number of
> > elements less than k in set and unfortunately regular std::set doesn't
> > provide such possibility although it would be extremely useful in
> > competitions.
> >
> > I made two posts about pbds on codeforces to introduce them to community:
> > https://codeforces.com/blog/entry/11080 and
> > https://codeforces.com/blog/entry/13279. First one introduces
> structures in
> > general and second one describes how to modify them so they support
> custom
> > queries. Second one was not quite as popular, perhaps because it's not
> much
> > easier to comprehend and remember concept than simply write something
> like
> > cartesian tree on live contest. But the first one is pretty much alive,
> > most recent comment was only 8 days ago.
> >
> > There was also another post (https://codeforces.com/blog/entry/60737)
> > considering hash_map from pb_ds as a replacement for unordered_map since
> > hash_map clearly outperform unordered_map. This one is also quite popular
> > and well-known in competitive programming community.
> >
> > So speaking about "Do you actually use these containers?" I would say
> that
> > I often use tree_order_statistics_node_update in competitions, and in
> > general specifically tree_order_statistics_node_update and hash_map are
> > pretty popular in competitive programming community.
> >
> > Deprecating policy based data structures will deal much pain to some
> > competitors because problems in which it's possible to use pbds instead
> of
> > custom balanced binary trees occur quite often and so now we'll have to
> > implement bbst instead of using something out of the box.
> >
> > Not sure if you would consider this usage case as something "serious",
> but
> > well, I was asked, so I answered.
>
> Thanks for responding!
>
> I don't really care about this use case, sorry. If the programming
> competition community were providing fixes or improvements for this
> code I might be more inclined to keep supported it, but it seems like
> we're just carrying around a huge chunk of code because it saves
> people some time in some competitions. Presumably the competition code
> is not reused, so there's no backwards compatibility issue here
> either.
>

Re: [GSoC-19] Implementing narrowing functions like fadd

[Tejas Joshi]

Hi all,
I have some doubts regarding narrowing functions. Functions like fadd
have different variants like fadd, faddl and daddl. These functions
differs from general floating point functions which have float and
long double argument types. These functions are defined in
builtins.def like floor, floorf and floorl with their respective
macros BUILT_IN_FLOOR, BUILT_IN_FLOORF and BUILT_IN_FLOORL. But for
fadd, fsub, fmul variants, float is not supposed to be one of the
argument types.

Also, CASE_MATHFN and CASE_MATHFN_FLOATN cases in builtins.c expand
normal, F and L variants which are assigned to respective fcode
built_in_function. This makes any function defined in builtins.def to
have F and L variants mandatory. How these narrowing functions are
supposed to be handled? Do we define another macro expansion like
CASE_MATHFN or have a manual case handling in mathfn_built_in_2?
Attached patch is what I have tried so far.

Thanks,
Tejas

On Wed, 10 Jul 2019 at 18:03, Richard Sandiford
 wrote:
>
> Tejas Joshi  writes:
> > Hello.
> > I have added fadd variants in builtins.def. For fadd and faddl
> > variants, I had to introduce builtin function types in
> > builtin-types.def :
> >
> > +DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT_DOUBLE_DOUBLE,
> > +BT_FLOAT, BT_DOUBLE, BT_DOUBLE)
> > +DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT_LONGDOUBLE_LONGDOUBLE,
> > +BT_FLOAT, BT_LONGDOUBLE, BT_LONGDOUBLE)
> >
> > and used them to define function in builtins.def. At this point, only
> > faddf variant is getting called by test program :
> >
> > int main ()
> > {
> > double z = __builtin_faddf (3.5, 1.4);
> > }
> > faddf variant is using BT_FN_FLOAT_FLOAT_FLOAT which is already
> > defined in builtin-types.def means I need not to introduce it. Why
> > fadd and faddl are not getting called in this patch? I don't find any
> > other place where these function types needs to be added.
>
> This is because of:
>
>   if (mode == arg0_mode
>   && real_cst_p (arg0)
>   && real_cst_p (arg1))
>
> in fold_const_call_1.  The reason for that check is that usually
> the format passed in to fold_const_call_sss applies to both arguments
> and the return type.  There's already an exception for CASE_CFN_NEXTTOWARD
> though.  I guess you'll need something similar here.
>
> Thanks,
> Richard
diff --git a/gcc/builtin-types.def b/gcc/builtin-types.def
index e5c9e063c48..6bc552fa71a 100644
--- a/gcc/builtin-types.def
+++ b/gcc/builtin-types.def
@@ -387,8 +387,14 @@ DEF_FUNCTION_TYPE_2 (BT_FN_VOID_UINT_PTR,
 		 BT_VOID, BT_UINT, BT_PTR)
 DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT_FLOAT_FLOAT,
 		 BT_FLOAT, BT_FLOAT, BT_FLOAT)
+DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT_DOUBLE_DOUBLE,
+		 BT_FLOAT, BT_DOUBLE, BT_DOUBLE)
+DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT_LONGDOUBLE_LONGDOUBLE,
+		 BT_FLOAT, BT_LONGDOUBLE, BT_LONGDOUBLE)
 DEF_FUNCTION_TYPE_2 (BT_FN_DOUBLE_DOUBLE_DOUBLE,
 		 BT_DOUBLE, BT_DOUBLE, BT_DOUBLE)
+DEF_FUNCTION_TYPE_2 (BT_FN_DOUBLE_LONGDOUBLE_LONGDOUBLE,
+		 BT_DOUBLE, BT_LONGDOUBLE, BT_LONGDOUBLE)
 DEF_FUNCTION_TYPE_2 (BT_FN_LONGDOUBLE_LONGDOUBLE_LONGDOUBLE,
 		 BT_LONGDOUBLE, BT_LONGDOUBLE, BT_LONGDOUBLE)
 DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT16_FLOAT16_FLOAT16,
diff --git a/gcc/builtins.c b/gcc/builtins.c
index 8ceb077b0bf..37c4206ec65 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -2006,6 +2006,7 @@ mathfn_built_in_2 (tree type, combined_fn fn)
 CASE_MATHFN (EXP2)
 CASE_MATHFN (EXPM1)
 CASE_MATHFN (FABS)
+CASE_MATHFN (FADD)
 CASE_MATHFN (FDIM)
 CASE_MATHFN_FLOATN (FLOOR)
 CASE_MATHFN_FLOATN (FMA)
diff --git a/gcc/builtins.def b/gcc/builtins.def
index 8bb7027aac7..2e749f038be 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -352,6 +352,12 @@ DEF_C99_C90RES_BUILTIN (BUILT_IN_FABSL, "fabsl", BT_FN_LONGDOUBLE_LONGDOUBLE, AT
 #define FABS_TYPE(F) BT_FN_##F##_##F
 DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_FABS, "fabs", FABS_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #undef FABS_TYPE
+DEF_EXT_LIB_BUILTIN(BUILT_IN_FADD, "fadd", BT_FN_FLOAT_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN(BUILT_IN_DADDL, "daddl", BT_FN_DOUBLE_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN(BUILT_IN_FADDL, "faddl", BT_FN_FLOAT_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
+#define FADD_TYPE(F) BT_FN_##F##_##F##_##F
+DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_FADD, "fadd", FADD_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
+#undef FADD_TYPE
 DEF_GCC_BUILTIN(BUILT_IN_FABSD32, "fabsd32", BT_FN_DFLOAT32_DFLOAT32, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_GCC_BUILTIN(BUILT_IN_FABSD64, "fabsd64", BT_FN_DFLOAT64_DFLOAT64, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_GCC_BUILTIN(BUILT_IN_FABSD128, "fabsd128", BT_FN_DFLOAT128_DFLOAT128, ATTR_CONST_NOTHROW_LEAF_LIST)
diff --git a/gcc/fold-const-call.c b/gcc/fold-const-call.c
index d9b546e6803..9f0e5510514 100644
--- a/gcc/fold-const-call.c
+++ b/gcc/fold-const-call.c
@@ -570,6 +570,16 @@ fold_const_nextaft

Re: Doubts regarding the _Dependent_ptr keyword

[Akshat Garg]

Hi all,

I have tried to make the dependent_ptr qualification act as volatile during
the RTL passes to bypass the RTL optimizations for now. Here is the patch
https://github.com/AKG001/gcc/commit/14c05ae546554f822f667fdb72080b7fe52fea32
For this (https://github.com/AKG001/test/blob/master/dependency_breaking.c)
example, I have been able to get this (
https://github.com/AKG001/test/blob/master/dependency_breaking.c.317r.final)
.final code. I believe that there are no dependencies that are broken.
Hoping someone else could also confirm if I have mistaken somewhere. I have
given the dependent_ptr qualification to only memory type objects for now.
The flag /d represents that this memory represents the dependent pointer in
.final code.
I am checking up the other examples form document P0190R4 to see what other
things need to be done. Let me know what you guys think.

-Akshat

On Mon, Jul 22, 2019 at 3:16 PM Richard Biener 
wrote:

> On Mon, Jul 22, 2019 at 10:54 AM Akshat Garg  wrote:
>
>> On Mon, Jul 22, 2019 at 2:11 PM Richard Biener <
>> richard.guent...@gmail.com> wrote:
>>
>>> On Mon, Jul 22, 2019 at 2:27 AM Akshat Garg  wrote:
>>>
 Hi all,
 Consider part of an example(figure 20) from doc P0190R4(
 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0190r4.pdf)
 shown below:

 1.  void thread1 (void)
 2.  {
 3.int * volatile p;
 4.p = rcu_dereference(gip);
 5.if (p)
 6.assert(*(p+p[0]) == 42);
 7.  }
 The .gimple code produced is :

 1.  thread1 ()
 2.  {
 3.   atomic int * D.1992;
 4.int * volatile p;
 5.  {
 6.atomic int * * __atomic_load_ptr;
 7.   atomic int * __atomic_load_tmp;
 8.try
 9. {
 10.__atomic_load_ptr = &gip;
 11._1 = __atomic_load_8 (__atomic_load_ptr, 1);
 12._2 = (atomic int *) _1;
 13.__atomic_load_tmp = _2;
 14.D.1992 = __atomic_load_tmp;
 15. }
 16.finally
 17.  {
 18.__atomic_load_tmp = {CLOBBER};
 19.  }
 20.  }
 21.   p = D.1992;
 22.   p.2_3 = p;
 23.  if (p.2_3 != 0B) goto ; else goto ;
 24.  :
 25.   p.3_4 = p;
 26.  p.4_5 = p;
 27.   _6 = *p.4_5;
 28.  _7 = (long unsigned int) _6;
 29.  _8 = _7 * 4;
 30.  _9 = p.3_4 + _8;
 31.  _10 = *_9;
 32.  _11 = _10 == 42;
 33.  _12 = (int) _11;
 34.  assert (_12);
 35.  :
 36. }

 assert at line 34 in .gimple code still breaks the dependency given by
 the user. I believe, there should be some ssa defined variable of p or p
 itself in assert. This is happening when I am considering pointer as
 volatile qualified. If I consider it as _Dependent_ptr qualified then it
 surely produces the broken dependency code. Let me know, if I wrong
 somewhere.


>>> p appears as memory here which we load its value to p.3_4 which we then
>>> offset by _8 and load from the
>>> computed address into _10 which then appears in the assert condition.  I
>>> think that's as good as it can
>>> get ...
>>>
>>> Richard.
>>>
>>
>> Thank you for your reply. For, the same example above, consider this (
>> https://github.com/AKG001/rtl_opt/blob/master/p0190r4_fig20.c.239r.cse1#L402)
>> instruction at rtl level changed form this (
>> https://github.com/AKG001/rtl_opt/blob/master/p0190r4_fig20.c.239r.cse1#L231)
>> during the cse pass. The variable p.2_3 gets replaced by a temporary _1 but
>> _1 is not any dependent pointer where, p.2_3 was. Is this also not breaking
>> any dependencies
>>
>
> I'm not sure.  In general CSE can break dependences.  If the dependent
> pointer chain needs to conver multiple levels of
> indirections from the original atomic operation you need to make sure to
> not expose atomics as CSEable.  Thus on
> RTL have them all UNSPECs.
>
> Richard.
>
>
>> -Akshat




 On Wed, Jul 17, 2019 at 4:23 PM Akshat Garg  wrote:

> On Tue, Jul 2, 2019 at 9:06 PM Jason Merrill  wrote:
>
>> On Mon, Jul 1, 2019 at 8:59 PM Paul E. McKenney <
>> paul...@linux.ibm.com> wrote:
>> >
>> > On Tue, Jul 02, 2019 at 05:58:48AM +0530, Akshat Garg wrote:
>> > > On Tue, Jun 25, 2019 at 9:49 PM Akshat Garg 
>> 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 
>> 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.
>> > > >> >
>> > > >>
>> > > >>
>> 

Re: Doubts regarding the _Dependent_ptr keyword

[Akshat Garg]

On Wed, Jul 24, 2019 at 1:41 AM Akshat Garg  wrote:

> Hi all,
>
> I have tried to make the dependent_ptr qualification act as volatile
> during the RTL passes to bypass the RTL optimizations for now. Here is the
> patch
> https://github.com/AKG001/gcc/commit/14c05ae546554f822f667fdb72080b7fe52fea32
> For this (https://github.com/AKG001/test/blob/master/dependency_breaking.c)
> example, I have been able to get this (
> https://github.com/AKG001/test/blob/master/dependency_breaking.c.317r.final)
> .final code. I believe that there are no dependencies that are broken.
> Hoping someone else could also confirm if I have mistaken somewhere. I have
> given the dependent_ptr qualification to only memory type objects for now.
> The flag /d represents that this memory represents the dependent pointer in
> .final code.
> I am checking up the other examples form document P0190R4 to see what
> other things need to be done. Let me know what you guys think.
>
Sorry, I forgot to give the .optimized code for the above example. Here, it
is
https://github.com/AKG001/test/blob/master/dependency_breaking.c.231t.optimize

May be needed.

>
> -Akshat
>
> On Mon, Jul 22, 2019 at 3:16 PM Richard Biener 
> wrote:
>
>> On Mon, Jul 22, 2019 at 10:54 AM Akshat Garg  wrote:
>>
>>> On Mon, Jul 22, 2019 at 2:11 PM Richard Biener <
>>> richard.guent...@gmail.com> wrote:
>>>
 On Mon, Jul 22, 2019 at 2:27 AM Akshat Garg  wrote:

> Hi all,
> Consider part of an example(figure 20) from doc P0190R4(
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0190r4.pdf)
> shown below:
>
> 1.  void thread1 (void)
> 2.  {
> 3.int * volatile p;
> 4.p = rcu_dereference(gip);
> 5.if (p)
> 6.assert(*(p+p[0]) == 42);
> 7.  }
> The .gimple code produced is :
>
> 1.  thread1 ()
> 2.  {
> 3.   atomic int * D.1992;
> 4.int * volatile p;
> 5.  {
> 6.atomic int * * __atomic_load_ptr;
> 7.   atomic int * __atomic_load_tmp;
> 8.try
> 9. {
> 10.__atomic_load_ptr = &gip;
> 11._1 = __atomic_load_8 (__atomic_load_ptr, 1);
> 12._2 = (atomic int *) _1;
> 13.__atomic_load_tmp = _2;
> 14.D.1992 = __atomic_load_tmp;
> 15. }
> 16.finally
> 17.  {
> 18.__atomic_load_tmp = {CLOBBER};
> 19.  }
> 20.  }
> 21.   p = D.1992;
> 22.   p.2_3 = p;
> 23.  if (p.2_3 != 0B) goto ; else goto ;
> 24.  :
> 25.   p.3_4 = p;
> 26.  p.4_5 = p;
> 27.   _6 = *p.4_5;
> 28.  _7 = (long unsigned int) _6;
> 29.  _8 = _7 * 4;
> 30.  _9 = p.3_4 + _8;
> 31.  _10 = *_9;
> 32.  _11 = _10 == 42;
> 33.  _12 = (int) _11;
> 34.  assert (_12);
> 35.  :
> 36. }
>
> assert at line 34 in .gimple code still breaks the dependency given by
> the user. I believe, there should be some ssa defined variable of p or p
> itself in assert. This is happening when I am considering pointer as
> volatile qualified. If I consider it as _Dependent_ptr qualified then it
> surely produces the broken dependency code. Let me know, if I wrong
> somewhere.
>
>
 p appears as memory here which we load its value to p.3_4 which we then
 offset by _8 and load from the
 computed address into _10 which then appears in the assert condition.
 I think that's as good as it can
 get ...

 Richard.

>>>
>>> Thank you for your reply. For, the same example above, consider this (
>>> https://github.com/AKG001/rtl_opt/blob/master/p0190r4_fig20.c.239r.cse1#L402)
>>> instruction at rtl level changed form this (
>>> https://github.com/AKG001/rtl_opt/blob/master/p0190r4_fig20.c.239r.cse1#L231)
>>> during the cse pass. The variable p.2_3 gets replaced by a temporary _1 but
>>> _1 is not any dependent pointer where, p.2_3 was. Is this also not breaking
>>> any dependencies
>>>
>>
>> I'm not sure.  In general CSE can break dependences.  If the dependent
>> pointer chain needs to conver multiple levels of
>> indirections from the original atomic operation you need to make sure to
>> not expose atomics as CSEable.  Thus on
>> RTL have them all UNSPECs.
>>
>> Richard.
>>
>>
>>> -Akshat
>
>
>
>
> On Wed, Jul 17, 2019 at 4:23 PM Akshat Garg  wrote:
>
>> On Tue, Jul 2, 2019 at 9:06 PM Jason Merrill 
>> wrote:
>>
>>> On Mon, Jul 1, 2019 at 8:59 PM Paul E. McKenney <
>>> paul...@linux.ibm.com> wrote:
>>> >
>>> > On Tue, Jul 02, 2019 at 05:58:48AM +0530, Akshat Garg wrote:
>>> > > On Tue, Jun 25, 2019 at 9:49 PM Akshat Garg 
>>> 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...@gmai