From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mib.mailinblack.com (mib.mailinblack.com [137.74.84.110]) by sourceware.org (Postfix) with ESMTPS id F0C5938930CE for ; Mon, 8 Feb 2021 12:25:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org F0C5938930CE Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kalrayinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=bddinechin@kalray.eu Received: from localhost (localhost [127.0.0.1]) by mib.mailinblack.com (Postfix) with ESMTP id E9C541A35BC for ; Mon, 8 Feb 2021 12:25:33 +0000 (UTC) Received: from mib.mailinblack.com (localhost [127.0.0.1]) by mib.mailinblack.com with SMTP (Mib Daemon ) id KKWJTGSX for gcc@gcc.gnu.org; Mon, 08 Feb 2021 12:25:33 +0000 (UTC) Received: from zimbra2.kalray.eu (zimbra2.kalray.eu [92.103.151.219]) by mib.mailinblack.com (Postfix) with ESMTPS id AE2B71A3592 for ; Mon, 8 Feb 2021 12:25:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra2.kalray.eu (Postfix) with ESMTP id 79CFE27E042D for ; Mon, 8 Feb 2021 13:25:33 +0100 (CET) Received: from zimbra2.kalray.eu ([127.0.0.1]) by localhost (zimbra2.kalray.eu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id rygh49sLvMVv for ; Mon, 8 Feb 2021 13:25:33 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra2.kalray.eu (Postfix) with ESMTP id 1379827E07D7 for ; Mon, 8 Feb 2021 13:25:33 +0100 (CET) X-Virus-Scanned: amavisd-new at zimbra2.kalray.eu Received: from zimbra2.kalray.eu ([127.0.0.1]) by localhost (zimbra2.kalray.eu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1PEcRsPqm7Xo for ; Mon, 8 Feb 2021 13:25:32 +0100 (CET) Received: from zimbra2.kalray.eu (localhost [127.0.0.1]) by zimbra2.kalray.eu (Postfix) with ESMTP id E49CA27E042D for ; Mon, 8 Feb 2021 13:25:32 +0100 (CET) Date: Mon, 8 Feb 2021 13:25:32 +0100 (CET) From: =?utf-8?Q?Beno=C3=AEt?= De Dinechin To: gcc@gcc.gnu.org Message-ID: <784286449.7176098.1612787132851.JavaMail.zimbra@kalray.eu> In-Reply-To: <1094575209.18861549.1606140937179.JavaMail.zimbra@kalray.eu> References: <1094575209.18861549.1606140937179.JavaMail.zimbra@kalray.eu> Subject: IA64 control speculation of loads MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_7176092_645502685.1612787132849" X-Originating-IP: [192.168.40.202] X-Mailer: Zimbra 9.0.0_GA_3990 (ZimbraWebClient - GC85 (Linux)/9.0.0_GA_3990) Thread-Topic: IA64 control speculation of loads Thread-Index: N9/KqkrN6j8DebU4PRYO5VMLbEd0zPzx0yWB X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 12:25:36 -0000 ------=_Part_7176092_645502685.1612787132849 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello,=20 Is there a way to activate control speculation of loads in GCC, starting wi= th the ia64 target? For a loop as simple as on GCC 7.5, I could not get any= :=20 double=20 list_sum(list_cell list)=20 {=20 double result =3D 0.0;=20 while (list->next) {=20 list =3D list->next;=20 result +=3D list->payload;=20 if (!list->next) break;=20 list =3D list->next;=20 result +=3D list->payload;=20 }=20 return result;=20 }=20 Kalray has developed a 64-bit Fisher-style VLIW architecture ('KVX') for us= e in a manycore processor it produces. These VLIW cores run Linux, and Kalr= ay develops GCC and LLVM code generators for them (see kvx compilers on htt= ps://godbolt.org/z/ZJGzje ). VLIW performance on non-numerical code is crit= ically dependent on the control speculation of loads. Being a Fischer-style= VLIW, the kvx architecture has dismissable loads instead of control specul= ative loads, so there is no need to create speculation check with recovery = code.=20 I first tried in prepass scheduling with SCHED_RGN, hoping from various com= ments in the source file that it could move loads across blocks (sched-rgn.= c:26 The first run performs interblock scheduling, moving insns between dif= ferent blocks in the same "region"). SCHED_EBB is not available in prepass = and SEL_SCHED does not work with control speculation: not only from experie= nce with the kvx retargeting where it breaks dataflow invariants, but also = as hinted by logic in ia64.c:ia64_set_sched_flags().=20 My question is whether GCC can or cannot do any control speculation of load= s during prepass scheduling. From what I observed, enabling control specula= tion in region scheduling only enables the load instructions to get ready e= arlier in their home basic block, not being scheduled in a dominator basic = block like expected to happen for improving performance in the above exampl= e.=20 Thanks for any advice.=20 Beno=C3=AEt Dinechin=20 ------=_Part_7176092_645502685.1612787132849 Content-Type: application/octet-stream; name=list_sum-ia64.s Content-Disposition: attachment; filename=list_sum-ia64.s Content-Transfer-Encoding: base64 CS5maWxlCSJsaXN0X3N1bS5jIgoJLnByZWQuc2FmZV9hY3Jvc3NfY2FsbHMgcDEtcDUscDE2LXA2 MwoJLnRleHQKCS5hbGlnbiAxNgoJLmFsaWduIDY0CgkuZ2xvYmFsIGxpc3Rfc3VtIwoJLnR5cGUJ bGlzdF9zdW0jLCBAZnVuY3Rpb24KCS5wcm9jIGxpc3Rfc3VtIwpsaXN0X3N1bToKCS5wcm9sb2d1 ZQoJLmJvZHkKCS5tbWYKCWxkOCByMTQgPSBbcjMyXQoJbm9wIDAKCW1vdiBmNiA9IGYwCgk7OwoJ Lm1taQoJY21wLmVxIHA2LCBwNyA9IDAsIHIxNAoJbm9wIDAKCWFkZHMgcjE1ID0gOCwgcjE0Cgk7 OwoJLm1mYgoJbm9wIDAKCShwNikgbW92IGY4ID0gZjAKCShwNikgYnIuY29uZC5kcG50IC5MMQoJ OzsKCS5tbWkKCWxkZmQgZjggPSBbcjE1XQoJbGQ4IHIxNCA9IFtyMTRdCglub3AgMAoJOzsKCS5t bWkKCW5vcCAwCgljbXAuZXEgcDYsIHA3ID0gMCwgcjE0Cglub3AgMAoJOzsKCS5tZmIKCW5vcCAw CglmYWRkLmQgZjggPSBmOCwgZjYKCShwNikgYnIuY29uZC5kcG50IC5MMQoJLmFsaWduIDMyCi5M MzoKCS5tbWkKCWFkZHMgcjE1ID0gOCwgcjE0CglsZDggcjE0ID0gW3IxNF0KCW5vcCAwCgk7OwoJ Lm1taQoJbGRmZCBmNiA9IFtyMTVdCglhZGRzIHIxNiA9IDgsIHIxNAoJY21wLm5lIHA2LCBwNyA9 IDAsIHIxNAoJOzsKCS5tZmIKCW5vcCAwCglmYWRkLmQgZjggPSBmOCwgZjYKCShwNykgYnIuY29u ZC5kcG50IC5MMQoJOzsKCS5tbWkKCWxkZmQgZjYgPSBbcjE2XQoJbGQ4IHIxNCA9IFtyMTRdCglu b3AgMAoJOzsKCS5tbWkKCW5vcCAwCgljbXAuZXEgcDYsIHA3ID0gMCwgcjE0Cglub3AgMAoJOzsK CS5tZmIKCW5vcCAwCglmYWRkLmQgZjggPSBmOCwgZjYKCShwNykgYnIuY29uZC5kcHRrIC5MMwou TDE6CgkubWliCglub3AgMAoJbm9wIDAKCWJyLnJldC5zcHRrLm1hbnkgYjAKCS5lbmRwIGxpc3Rf c3VtIwoJLmlkZW50CSJHQ0M6IChHTlUpIDcuNS4wIgo= ------=_Part_7176092_645502685.1612787132849 Content-Type: application/octet-stream; name=list_sum-kvx.s Content-Disposition: attachment; filename=list_sum-kvx.s Content-Transfer-Encoding: base64 CS5maWxlCSJsaXN0X3N1bS5jIgoJLnRleHQKCgkuYWxpZ24gOAoJLmdsb2JhbCBsaXN0X3N1bQoJ LnR5cGUJbGlzdF9zdW0sIEBmdW5jdGlvbgpsaXN0X3N1bToKCWxkICRyMCA9IDBbJHIwXQoJbWFr ZSAkcjIgPSAweDAwMDAwMDAwMDAwMDAwMDAKCTs7CShlbmQgY3ljbGUgMCkKCWNiLmRlcXogJHIw PyAuTDUKCTs7CShlbmQgY3ljbGUgNCkKCWxkICRyMSA9IDBbJHIwXQoJOzsJKGVuZCBjeWNsZSA1 KQoJbGQgJHIwID0gOFskcjBdCgk7OwkoZW5kIGN5Y2xlIDYpCglmYWRkZCAkcjAgPSAkcjAsICRy MgoJY2IuZG5leiAkcjE/IC5MMwoJOzsJKGVuZCBjeWNsZSA5KQoJZ290byAuTDEKCTs7CShlbmQg Y3ljbGUgMCkKLkw0OgoJbGQgJHIxID0gMFskcjJdCgk7OwkoZW5kIGN5Y2xlIDApCglsZCAkcjIg PSA4WyRyMl0KCTs7CShlbmQgY3ljbGUgMSkKCWZhZGRkICRyMCA9ICRyMCwgJHIyCgljYi5kZXF6 ICRyMT8gLkwxCgk7OwkoZW5kIGN5Y2xlIDQpCi5MMzoKCWxkICRyMiA9IDBbJHIxXQoJOzsJKGVu ZCBjeWNsZSAwKQoJbGQgJHIxID0gOFskcjFdCgk7OwkoZW5kIGN5Y2xlIDEpCglmYWRkZCAkcjAg PSAkcjAsICRyMQoJY2IuZG5leiAkcjI/IC5MNAoJOzsJKGVuZCBjeWNsZSA0KQouTDE6CglyZXQK CTs7CShlbmQgY3ljbGUgMCkKLkw1OgoJbWFrZSAkcjAgPSAweDAwMDAwMDAwMDAwMDAwMDAKCXJl dAoJOzsJKGVuZCBjeWNsZSAwKQoJLnNpemUJbGlzdF9zdW0sIC4tbGlzdF9zdW0KCS5pZGVudAki R0NDOiAoR05VKSA3LjUuMCIK ------=_Part_7176092_645502685.1612787132849--