From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48526 invoked by alias); 17 Jul 2019 09:34:36 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 48516 invoked by uid 89); 17 Jul 2019 09:34:36 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,KAM_LOTSOFHASH,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.1 spammy=7, arise, H*c:alternative, us X-HELO: mail-ot1-f44.google.com Received: from mail-ot1-f44.google.com (HELO mail-ot1-f44.google.com) (209.85.210.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 17 Jul 2019 09:34:34 +0000 Received: by mail-ot1-f44.google.com with SMTP id r21so18251813otq.6 for ; Wed, 17 Jul 2019 02:34:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=OJkh6+1eJXhnRmn8ZwawZGyntHNBzAgQ1hoBCWOOEvQ=; b=DutXdSQgWt37zRVgVELENtdYcXKpW8eLuLoAl3/H0157YmEmXxUPx2kqbuAgGogc0U p+t0NEYi5Gm05xZ7YxbV0TYQXI2WzmpItFuZPA1DOLUFB9Flp3E8MSfUYEjgdOcHRmP5 hw2JnUrDhV1/RoCTr04e8CK4urVjg9zWefpCGmZqicz+XR3aZBl5jccx5SREFldrH+oZ jhBnNOgKC2gbRlPpNjUvV8uroJ2zPMBLvBgZfD53TzS9rCIRS/87lE1GeqXtqvLR/UDA HdLGss24XLVLYFcTPYBTbCrrCkmZkOuPo8e96VuTRxc+ZKJCU55/a5iIGIOrXAXg8sBn rzig== MIME-Version: 1.0 From: Akshat Garg Date: Wed, 17 Jul 2019 09:34:00 -0000 Message-ID: Subject: _Dependent_ptr problems in RTL passes To: gcc mailing list Cc: Paul McKenney , Ramana Radhakrishnan , Richard Biener , Jakub Jelinek , Jason Merrill Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2019-07/txt/msg00113.txt.bz2 Hi all, We are working on making memory_order_consume not get promoted to memory_order_acquire. Here is a little background on the work we are doing https://gcc.gnu.org/ml/gcc/2019-07/msg00038.html We are able to parse _Dependent_ptr from C front-end. The patch files are given here. https://github.com/AKG001/gcc/commit/2accdd2b43100abae937c714eb4c8e385940b5c7 https://github.com/AKG001/gcc/commit/fb4187bc3872a50880159232cf336f0a03505fa8 Currently, we are working over the pointers only. As discussed earlier, there are certain passes, on the tree and RTL level, that may break the dependencies specified by the user. We are interested to know about the problems that could arise during the RTL passes. For that, we have tried to skip the tree passes, by considering the _Dependent_ptr as volatile. The patch for this here. https://github.com/AKG001/gcc/commit/e4ffd77f62ace986c124a70b90a662c083c570ba We are trying to find all the passes where the dependencies could get broken. We have experimented on certain examples, and we have some doubts regarding an example. Hoping community people can help us. The example is figure 20 from here ( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0190r4.pdf). The example: (https://github.com/AKG001/rtl_opt/blob/master/p0190r4_fig20.c). The .optimized code: https://github.com/AKG001/rtl_opt/blob/master/p0190r4_fig20.c.231t.optimized The .expand code: https://github.com/AKG001/rtl_opt/blob/master/p0190r4_fig20.c.233r.expand The .cse1 code: https://github.com/AKG001/rtl_opt/blob/master/p0190r4_fig20.c.239r.cse1 The .final code: https://github.com/AKG001/rtl_opt/blob/master/p0190r4_fig20.c.317r.final In the .expand code, I believe there are no dependencies that gets broken. Hoping someone could also verify. But, in .cse1 code instruction at line at line 231, as shown below, 1. (insn 10 9 11 2 (set (reg:CCZ 17 flags) 2. (compare:CCZ (reg/f:DI 84 [ p.2_3 ]) 3. (const_int 0 [0]))) "p0190r4_fig20.c":44:6 8 {*cmpdi_ccno_1} 4. (nil)) and instruction at line 402, as shown below 5. (insn 10 9 11 2 (set (reg:CCZ 17 flags) 6. (compare:CCZ (reg:DI 82 [ _1 ]) 7. (const_int 0 [0]))) "p0190r4_fig20.c":44:6 8 {*cmpdi_ccno_1} 8. (expr_list:REG_DEAD (reg/f:DI 84 [ p.2_3 ]) 9. (nil))) dependencies get broken. The instruction starting at line 1 gets changed to instruction starting at line 5 and starts referring to variable _1 which is defined as " long unsigned int _1;" in the .optimized code in thread1(), which is a temporary variable. I believe, this breaks the dependencies specified by the user and for that we need to put some code inside cse.c file. Also, many versions for variable 'p' gets created shown in .optimized code, they all should have _dependent_ptr qualification which they don't have currently. I believe, simply bypassing the tree passes through volatile checks won't mark them as dependent pointer qualified. For this, I believe, we need to tweak the ssa generation pass(tree-ssa.c) somewhat. Thank you all and let me know if anyone finds me wrong anywhere. -Akshat