[{"id":1763195,"web_url":"http://patchwork.ozlabs.org/comment/1763195/","msgid":"","list_archive_url":null,"date":"2017-09-05T10:35:20","subject":"Re: [PATCH,\n\tmiddle-end]: Introduce memory_blockage named insn pattern","submitter":{"id":5136,"url":"http://patchwork.ozlabs.org/api/people/5136/","name":"Alexander Monakov","email":"amonakov@ispras.ru"},"content":"On Tue, 5 Sep 2017, Uros Bizjak wrote:\n> This patch allows to emit memory_blockage pattern instead of default\n> asm volatile as a memory blockage. This patch is needed, so targets\n> (e.g. x86) can define and emit more optimal memory blockage pseudo\n> insn.\n\nOptimal in what sense? What pattern do you intend to use on x86, and\nwould any target be able to use the same?\n\n\n> And let's call scheduler memory barriers a \"memory blockage\"\n> pseudo insn, not \"memory barrier\" which should describe real\n> instruction.\n\nNote this is not about scheduling, but all RTL passes. This (pseudo-)\ninstruction is meant to prevent all memory movement across it, including\nRTL CSE, RTL DSE, etc.\n\nAlexander","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list gcc-patches@gcc.gnu.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=gcc-patches-return-461482-incoming=patchwork.ozlabs.org@gcc.gnu.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org\n\theader.b=\"S1YF9YMK\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xmjm90Grdz9s71\n\tfor ;\n\tTue, 5 Sep 2017 20:35:36 +1000 (AEST)","(qmail 109403 invoked by alias); 5 Sep 2017 10:35:28 -0000","(qmail 109288 invoked by uid 89); 5 Sep 2017 10:35:27 -0000","from bran.ispras.ru (HELO smtp.ispras.ru) (83.149.199.196) by\n\tsourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP;\n\tTue, 05 Sep 2017 10:35:22 +0000","from monopod.intra.ispras.ru (monopod.intra.ispras.ru\n\t[10.10.3.121])\tby smtp.ispras.ru (Postfix) with ESMTP id\n\t911A0203D0; Tue, 5 Sep 2017 13:35:20 +0300 (MSK)"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender:date\n\t:from:to:cc:subject:in-reply-to:message-id:references\n\t:mime-version:content-type; q=dns; s=default; b=rSfgSn3xq5l6tNR7\n\tXP9Wcbf47cr17DNAuSXOkAg8AighDaGmXb4kbuEYDxHEx3T/s6FYxBqhX+X2lA82\n\tvSOVWJKKg/iodGYuIjWcaEUUxXwu7gdwQLKHSnLI+IzEVPyYVxfjCyMMsjWoPzlo\n\t6R/OoAuj8hRteUBKHlHp4SF2ekg=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender:date\n\t:from:to:cc:subject:in-reply-to:message-id:references\n\t:mime-version:content-type; s=default; bh=nhyyoSmKMX2fKH3bhPTowQ\n\tnGeEE=; b=S1YF9YMK4mLcauzgtll4b1k9ldhM2nm5ojXFNQjlFGq5ZWbytGXEHr\n\tEJ7Onk/l/NY9ZSjzsFul3FwlLfCmrCIAQuoqy2AV9bg6LwmhcxB1WznIFh/6QXgn\n\t1wMB0SPofmyMKHH6teZP9USvwf4vlnTlV/4eo1h7I/QjNLXB4qW0M=","Mailing-List":"contact gcc-patches-help@gcc.gnu.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Archive":"","List-Post":"","List-Help":"","Sender":"gcc-patches-owner@gcc.gnu.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-2.2 required=5.0 tests=AWL, BAYES_00,\n\tRP_MATCHES_RCVD, SPF_PASS autolearn=ham version=3.3.2 spammy=","X-HELO":"smtp.ispras.ru","Date":"Tue, 5 Sep 2017 13:35:20 +0300 (MSK)","From":"Alexander Monakov ","To":"Uros Bizjak ","cc":"\"gcc-patches@gcc.gnu.org\" ","Subject":"Re: [PATCH,\n\tmiddle-end]: Introduce memory_blockage named insn pattern","In-Reply-To":"","Message-ID":"","References":"","User-Agent":"Alpine 2.20.13 (LNX 116 2015-12-14)","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII"}},{"id":1763220,"web_url":"http://patchwork.ozlabs.org/comment/1763220/","msgid":"","list_archive_url":null,"date":"2017-09-05T11:08:39","subject":"Re: [PATCH,\n\tmiddle-end]: Introduce memory_blockage named insn pattern","submitter":{"id":808,"url":"http://patchwork.ozlabs.org/api/people/808/","name":"Uros Bizjak","email":"ubizjak@gmail.com"},"content":"On Tue, Sep 5, 2017 at 12:35 PM, Alexander Monakov wrote:\n> On Tue, 5 Sep 2017, Uros Bizjak wrote:\n>> This patch allows to emit memory_blockage pattern instead of default\n>> asm volatile as a memory blockage. This patch is needed, so targets\n>> (e.g. x86) can define and emit more optimal memory blockage pseudo\n>> insn.\n>\n> Optimal in what sense? What pattern do you intend to use on x86, and\n> would any target be able to use the same?\n\nYou don't have to emit a generic asm-like pattern. This is the same\nsituation as with blockage insn, where targets can emit \"blockage\"\ninstead of generic asm insn.\n\nx86 defines memory_blockage as:\n\n(define_expand \"memory_blockage\"\n [(set (match_dup 0)\n (unspec:BLK [(match_dup 0)] UNSPEC_MEMORY_BLOCKAGE))]\n \"\"\n{\n operands[0] = gen_rtx_MEM (BLKmode, gen_rtx_SCRATCH (Pmode));\n MEM_VOLATILE_P (operands[0]) = 1;\n})\n\nHowever, this definition can't be generic, since unspec is used.\n\n>> And let's call scheduler memory barriers a \"memory blockage\"\n>> pseudo insn, not \"memory barrier\" which should describe real\n>> instruction.\n>\n> Note this is not about scheduling, but all RTL passes. This (pseudo-)\n> instruction is meant to prevent all memory movement across it, including\n> RTL CSE, RTL DSE, etc.\n\nYes, the above insn satisfies all mentioned use cases.\n\nOh, I noticed that I attach the wrong version of the patch. Correct\nversion attached.\n\nUros.\ndiff --git a/gcc/doc/md.texi b/gcc/doc/md.texi\nindex 14aab9474bc2..df4dc8ccd0e1 100644\n--- a/gcc/doc/md.texi\n+++ b/gcc/doc/md.texi\n@@ -6734,6 +6734,13 @@ scheduler and other passes from moving instructions and using register\n equivalences across the boundary defined by the blockage insn.\n This needs to be an UNSPEC_VOLATILE pattern or a volatile ASM.\n \n+@cindex @code{memmory_blockage} instruction pattern\n+@item @samp{memory_blockage}\n+This pattern defines a pseudo insn that prevents the instruction\n+scheduler and other passes from moving instructions accessing memory\n+across the boundary defined by the blockage insn. This instruction\n+needs to read and write volatile BLKmode memory.\n+\n @cindex @code{memory_barrier} instruction pattern\n @item @samp{memory_barrier}\n If the target memory model is not fully synchronous, then this pattern\ndiff --git a/gcc/optabs.c b/gcc/optabs.c\nindex b65707080eee..5821d2a9547c 100644\n--- a/gcc/optabs.c\n+++ b/gcc/optabs.c\n@@ -6276,10 +6276,10 @@ expand_atomic_compare_and_swap (rtx *ptarget_bool, rtx *ptarget_oval,\n return true;\n }\n \n-/* Generate asm volatile(\"\" : : : \"memory\") as the memory barrier. */\n+/* Generate asm volatile(\"\" : : : \"memory\") as the memory blockage. */\n \n static void\n-expand_asm_memory_barrier (void)\n+expand_asm_memory_blockage (void)\n {\n rtx asm_op, clob;\n \n@@ -6295,6 +6295,21 @@ expand_asm_memory_barrier (void)\n emit_insn (gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2, asm_op, clob)));\n }\n \n+#ifndef HAVE_memory_blockage\n+#define HAVE_memory_blockage 0\n+#endif\n+\n+/* Do not schedule instructions accessing memory across this point. */\n+\n+static void\n+expand_memory_blockage (void)\n+{\n+ if (HAVE_memory_blockage)\n+ emit_insn (gen_memory_blockage ());\n+ else\n+ expand_asm_memory_blockage ();\n+}\n+\n /* This routine will either emit the mem_thread_fence pattern or issue a \n sync_synchronize to generate a fence for memory model MEMMODEL. */\n \n@@ -6306,14 +6321,14 @@ expand_mem_thread_fence (enum memmodel model)\n if (targetm.have_mem_thread_fence ())\n {\n emit_insn (targetm.gen_mem_thread_fence (GEN_INT (model)));\n- expand_asm_memory_barrier ();\n+ expand_memory_blockage ();\n }\n else if (targetm.have_memory_barrier ())\n emit_insn (targetm.gen_memory_barrier ());\n else if (synchronize_libfunc != NULL_RTX)\n emit_library_call (synchronize_libfunc, LCT_NORMAL, VOIDmode);\n else\n- expand_asm_memory_barrier ();\n+ expand_memory_blockage ();\n }\n \n /* Emit a signal fence with given memory model. */\n@@ -6324,7 +6339,7 @@ expand_mem_signal_fence (enum memmodel model)\n /* No machine barrier is required to implement a signal fence, but\n a compiler memory barrier must be issued, except for relaxed MM. */\n if (!is_mm_relaxed (model))\n- expand_asm_memory_barrier ();\n+ expand_memory_blockage ();\n }\n \n /* This function expands the atomic load operation:\n@@ -6346,7 +6361,7 @@ expand_atomic_load (rtx target, rtx mem, enum memmodel model)\n struct expand_operand ops[3];\n rtx_insn *last = get_last_insn ();\n if (is_mm_seq_cst (model))\n-\texpand_asm_memory_barrier ();\n+\texpand_memory_blockage ();\n \n create_output_operand (&ops[0], target, mode);\n create_fixed_operand (&ops[1], mem);\n@@ -6354,7 +6369,7 @@ expand_atomic_load (rtx target, rtx mem, enum memmodel model)\n if (maybe_expand_insn (icode, 3, ops))\n \t{\n \t if (!is_mm_relaxed (model))\n-\t expand_asm_memory_barrier ();\n+\t expand_memory_blockage ();\n \t return ops[0].value;\n \t}\n delete_insns_since (last);\n@@ -6404,14 +6419,14 @@ expand_atomic_store (rtx mem, rtx val, enum memmodel model, bool use_release)\n {\n rtx_insn *last = get_last_insn ();\n if (!is_mm_relaxed (model))\n-\texpand_asm_memory_barrier ();\n+\texpand_memory_blockage ();\n create_fixed_operand (&ops[0], mem);\n create_input_operand (&ops[1], val, mode);\n create_integer_operand (&ops[2], model);\n if (maybe_expand_insn (icode, 3, ops))\n \t{\n \t if (is_mm_seq_cst (model))\n-\t expand_asm_memory_barrier ();\n+\t expand_memory_blockage ();\n \t return const0_rtx;\n \t}\n delete_insns_since (last);","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list gcc-patches@gcc.gnu.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=gcc-patches-return-461486-incoming=patchwork.ozlabs.org@gcc.gnu.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org\n\theader.b=\"O+iTC9kt\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xmkVl2hF8z9sPk\n\tfor ;\n\tTue, 5 Sep 2017 21:09:03 +1000 (AEST)","(qmail 115025 invoked by alias); 5 Sep 2017 11:08:53 -0000","(qmail 114839 invoked by uid 89); 5 Sep 2017 11:08:52 -0000","from mail-ua0-f193.google.com (HELO mail-ua0-f193.google.com)\n\t(209.85.217.193) by sourceware.org\n\t(qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP;\n\tTue, 05 Sep 2017 11:08:41 +0000","by mail-ua0-f193.google.com with SMTP id k23so1128582uaf.3 for\n\t; Tue, 05 Sep 2017 04:08:41 -0700 (PDT)","by 10.103.55.28 with HTTP; Tue, 5 Sep 2017 04:08:39 -0700 (PDT)"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender\n\t:mime-version:in-reply-to:references:from:date:message-id\n\t:subject:to:cc:content-type; q=dns; s=default; b=aIZ47vAxNJKNn7K\n\t/67NLgeKNx/aij3XoT9Bg8AcKF+31bVVyGimGHHlKjoIiOe3IfLmdg8e0efPb2in\n\tse1Gwryn2JrqdWiWmVWw9qqyU8TiGWkR09ZDmt4wSYIg2T0/gmmjg3V1iiU1nZAX\n\tnb6aJaFuybWGqp591Nshs6aIiqDk=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender\n\t:mime-version:in-reply-to:references:from:date:message-id\n\t:subject:to:cc:content-type; s=default; bh=wFcAylEGt+qM+u1DQNl+t\n\toxtJR0=; b=O+iTC9ktXDYAvVx9mzuIiKYkHbw/JQP0diq4V6xBw/spfciEa3pV1\n\tlcD9GgGS8vToyefaPbXf4eRvReAzahm/dx5OPTi/XTGsZkoT0wU2cNi87Rpisyn+\n\triFMYE3Sziqn6OdQr3alYFs1lAvHxZ6H2tRoN6nF9DdNVUx8GGgaUM=","Mailing-List":"contact gcc-patches-help@gcc.gnu.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Archive":"","List-Post":"","List-Help":"","Sender":"gcc-patches-owner@gcc.gnu.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-24.3 required=5.0 tests=AWL, BAYES_00,\n\tFREEMAIL_FROM, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2,\n\tGIT_PATCH_3, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM,\n\tSPF_PASS autolearn=ham version=3.3.2 spammy=","X-HELO":"mail-ua0-f193.google.com","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net;\n\ts=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=meB/uMFP/ZE17TOhs4K3hhnbq9YgjQhpR535zc47URQ=;\n\tb=kBBYAoIY0gJ3RQ2Wr7FbTxb8+hZEHlpyDdA3h79IkyB/NhyrKdnSJRa8/4eZGskGlX\n\tBKmDGnN6Rff/Moy9abGfxvu9j0Af+cVqAui6T5pC/Q369BgVSNIczd3V/XW2N4yOmJCc\n\tI2dHGiMhyRfT0TdzIa5t71vJ0vKfxQ+69LlrGf83Fm5KFjdwFkpM996lyHuSkDbEgwG0\n\tAdCCEha1QKZ5gPvB1zQk3BLfPPDC9IHRw9puPIPZIv6AdRk2hL3oc4i3m6ImIMnQdAUH\n\tQw209c1Ip1JVycex9i0WlD8bylr+eujiSytchbuAIRjMnlKCkdJWjA6B5kAcP77cbf16\n\tT+Hg==","X-Gm-Message-State":"AHPjjUg4iTfm9jInaYkEpA1U+e2afzg7z3ZaVP9pEupNu16Yq4oEBrjg\t1Ts5WX1ALmOwy3OcfoYOsK4NoAjxCcwM","X-Google-Smtp-Source":"ADKCNb6o2JMdsYnACIsQYJWiGwI77B1/g5GGAleG8hrg4yaUv4XppLJf5xvyR5zP3kXbblZ4WCW+PjMswTK98pzY5i0=","X-Received":"by 10.176.69.243 with SMTP id u106mr2369505uau.22.1504609719861;\n\tTue, 05 Sep 2017 04:08:39 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"\n\t","From":"Uros Bizjak ","Date":"Tue, 5 Sep 2017 13:08:39 +0200","Message-ID":"","Subject":"Re: [PATCH,\n\tmiddle-end]: Introduce memory_blockage named insn pattern","To":"Alexander Monakov ","Cc":"\"gcc-patches@gcc.gnu.org\" ","Content-Type":"multipart/mixed; boundary=\"94eb2c11be74e0e54305586f3fd8\""}},{"id":1763274,"web_url":"http://patchwork.ozlabs.org/comment/1763274/","msgid":"","list_archive_url":null,"date":"2017-09-05T12:03:14","subject":"Re: [PATCH,\n\tmiddle-end]: Introduce memory_blockage named insn pattern","submitter":{"id":5136,"url":"http://patchwork.ozlabs.org/api/people/5136/","name":"Alexander Monakov","email":"amonakov@ispras.ru"},"content":"On Tue, 5 Sep 2017, Uros Bizjak wrote:\n> However, this definition can't be generic, since unspec is used.\n\nI see, if the only reason this needs a named pattern is lack of generic UNSPEC\nvalues, I believe it would be helpful to mention that in the documentation.\n\nA few comments on the patch:\n\n> @@ -6734,6 +6734,13 @@ scheduler and other passes from moving instructions and using register\n> equivalences across the boundary defined by the blockage insn.\n> This needs to be an UNSPEC_VOLATILE pattern or a volatile ASM.\n> \n> +@cindex @code{memmory_blockage} instruction pattern\n\nTypo ('mm').\n\n> +@item @samp{memory_blockage}\n> +This pattern defines a pseudo insn that prevents the instruction\n> +scheduler and other passes from moving instructions accessing memory\n> +across the boundary defined by the blockage insn. This instruction\n> +needs to read and write volatile BLKmode memory.\n> +\n\nI see this is mostly cloned from the 'blockage' pattern description, but\nthis is not quite correct, it's not about moving _instructions_ per se\n(RTL CSE propagates values loaded from memory without moving instructions,\nRTL DSE eliminates some stores to memory also without moving instructions),\nand calling out the scheduler separately doesn't seem useful. I suggest:\n\n\"\"\"\nThis pattern, if defined, represents a compiler memory barrier, and will be\nplaced at points across which RTL passes may not propagate memory accesses.\nThis instruction needs to read and write volatile BLKmode memory. It does\nnot need to generate any machine instruction, and like the @code{blockage}\ninsn needs a named pattern only because there are no generic @code{unspec}\nvalues. If this pattern is not defined, the compiler falls back by emitting\nan instruction corresponding to @code{asm volatile (\"\" ::: \"memory\")}.\n\"\"\"\n\n> @@ -6295,6 +6295,21 @@ expand_asm_memory_barrier (void)\n> emit_insn (gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2, asm_op, clob)));\n> }\n> \n> +#ifndef HAVE_memory_blockage\n> +#define HAVE_memory_blockage 0\n> +#endif\n\nWhy this? This style is not used (anymore) elsewhere in the file, afaict\nthe current approach is to add a definition in target-insns.def and then\nuse targetm.have_memory_blockage (e.g. like mem_thread_fence is used).\n\nThanks.\nAlexander","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list gcc-patches@gcc.gnu.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=gcc-patches-return-461498-incoming=patchwork.ozlabs.org@gcc.gnu.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org\n\theader.b=\"o8jX5iWS\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xmljd65S9z9sPt\n\tfor ;\n\tTue, 5 Sep 2017 22:03:32 +1000 (AEST)","(qmail 83372 invoked by alias); 5 Sep 2017 12:03:21 -0000","(qmail 83358 invoked by uid 89); 5 Sep 2017 12:03:21 -0000","from bran.ispras.ru (HELO smtp.ispras.ru) (83.149.199.196) by\n\tsourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP;\n\tTue, 05 Sep 2017 12:03:16 +0000","from monopod.intra.ispras.ru (monopod.intra.ispras.ru\n\t[10.10.3.121])\tby smtp.ispras.ru (Postfix) with ESMTP id\n\t20AD9203C7; Tue, 5 Sep 2017 15:03:14 +0300 (MSK)"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender:date\n\t:from:to:cc:subject:in-reply-to:message-id:references\n\t:mime-version:content-type; q=dns; s=default; b=DiCNeZ8CO5eD6XF2\n\t9S1EhERoFRIERwi5ti411QwgndW/zwCIaN5nNOpNdLiR+bDo6yex4kfNdYox5YEq\n\tqLLKF/nr4bAqgGV37FGRnWkbgzwC3cm5hpZeod4RkW6FE8XDKrSuxV0MatQVPq7/\n\tCUFX4iwtwDt619RCsmjark5zUi8=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender:date\n\t:from:to:cc:subject:in-reply-to:message-id:references\n\t:mime-version:content-type; s=default; bh=h3Ob/Ph15l3b29AYQsl5vD\n\t12Bqo=; b=o8jX5iWShW6vZ4+B55Njca31BM6qucH0s6lTMmjFbHJ1y2k16Lw/0t\n\tG5guBzD+ffrSyyZfQDy1ddeXIBjnY8TZ/jVC0PxMosKpockt3PhiDVhZOlrq3M5I\n\tgqak7UqRET7gKfOYafRT+9oCyyQI50VtR4EMJG+es4NSd7JamHdFw=","Mailing-List":"contact gcc-patches-help@gcc.gnu.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Archive":"","List-Post":"","List-Help":"","Sender":"gcc-patches-owner@gcc.gnu.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-6.7 required=5.0 tests=AWL, BAYES_00,\n\tGIT_PATCH_1, RP_MATCHES_RCVD,\n\tSPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2311","X-HELO":"smtp.ispras.ru","Date":"Tue, 5 Sep 2017 15:03:14 +0300 (MSK)","From":"Alexander Monakov ","To":"Uros Bizjak ","cc":"\"gcc-patches@gcc.gnu.org\" ","Subject":"Re: [PATCH,\n\tmiddle-end]: Introduce memory_blockage named insn pattern","In-Reply-To":"","Message-ID":"","References":"\n\t\n\t","User-Agent":"Alpine 2.20.13 (LNX 116 2015-12-14)","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII"}},{"id":1763276,"web_url":"http://patchwork.ozlabs.org/comment/1763276/","msgid":"","list_archive_url":null,"date":"2017-09-05T12:08:39","subject":"Re: [PATCH,\n\tmiddle-end]: Introduce memory_blockage named insn pattern","submitter":{"id":808,"url":"http://patchwork.ozlabs.org/api/people/808/","name":"Uros Bizjak","email":"ubizjak@gmail.com"},"content":"On Tue, Sep 5, 2017 at 2:03 PM, Alexander Monakov wrote:\n> On Tue, 5 Sep 2017, Uros Bizjak wrote:\n>> However, this definition can't be generic, since unspec is used.\n>\n> I see, if the only reason this needs a named pattern is lack of generic UNSPEC\n> values, I believe it would be helpful to mention that in the documentation.\n>\n> A few comments on the patch:\n>\n>> @@ -6734,6 +6734,13 @@ scheduler and other passes from moving instructions and using register\n>> equivalences across the boundary defined by the blockage insn.\n>> This needs to be an UNSPEC_VOLATILE pattern or a volatile ASM.\n>>\n>> +@cindex @code{memmory_blockage} instruction pattern\n>\n> Typo ('mm').\n>\n>> +@item @samp{memory_blockage}\n>> +This pattern defines a pseudo insn that prevents the instruction\n>> +scheduler and other passes from moving instructions accessing memory\n>> +across the boundary defined by the blockage insn. This instruction\n>> +needs to read and write volatile BLKmode memory.\n>> +\n>\n> I see this is mostly cloned from the 'blockage' pattern description, but\n> this is not quite correct, it's not about moving _instructions_ per se\n> (RTL CSE propagates values loaded from memory without moving instructions,\n> RTL DSE eliminates some stores to memory also without moving instructions),\n> and calling out the scheduler separately doesn't seem useful. I suggest:\n>\n> \"\"\"\n> This pattern, if defined, represents a compiler memory barrier, and will be\n> placed at points across which RTL passes may not propagate memory accesses.\n> This instruction needs to read and write volatile BLKmode memory. It does\n> not need to generate any machine instruction, and like the @code{blockage}\n> insn needs a named pattern only because there are no generic @code{unspec}\n> values. If this pattern is not defined, the compiler falls back by emitting\n> an instruction corresponding to @code{asm volatile (\"\" ::: \"memory\")}.\n> \"\"\"\n>\n>> @@ -6295,6 +6295,21 @@ expand_asm_memory_barrier (void)\n>> emit_insn (gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2, asm_op, clob)));\n>> }\n>>\n>> +#ifndef HAVE_memory_blockage\n>> +#define HAVE_memory_blockage 0\n>> +#endif\n>\n> Why this? This style is not used (anymore) elsewhere in the file, afaict\n> the current approach is to add a definition in target-insns.def and then\n> use targetm.have_memory_blockage (e.g. like mem_thread_fence is used).\n\nUh, I was not aware of the new approach. Will send a v2 with mentioned\nissues fixed.\n\nThanks,\nUros.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list gcc-patches@gcc.gnu.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=gcc-patches-return-461499-incoming=patchwork.ozlabs.org@gcc.gnu.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org\n\theader.b=\"qAkKsbMp\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xmlqq5gSJz9sPt\n\tfor ;\n\tTue, 5 Sep 2017 22:08:54 +1000 (AEST)","(qmail 87562 invoked by alias); 5 Sep 2017 12:08:47 -0000","(qmail 87541 invoked by uid 89); 5 Sep 2017 12:08:46 -0000","from mail-vk0-f65.google.com (HELO mail-vk0-f65.google.com)\n\t(209.85.213.65) by sourceware.org\n\t(qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP;\n\tTue, 05 Sep 2017 12:08:41 +0000","by mail-vk0-f65.google.com with SMTP id t10so1002373vke.2 for\n\t; Tue, 05 Sep 2017 05:08:41 -0700 (PDT)","by 10.103.55.28 with HTTP; Tue, 5 Sep 2017 05:08:39 -0700 (PDT)"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender\n\t:mime-version:in-reply-to:references:from:date:message-id\n\t:subject:to:cc:content-type; q=dns; s=default; b=CmGGOmiLbrTvNgo\n\tVNbqOGmFBelqSTrbq3Joq9/dwae5IYx7O6vhIzDzan182AopsNF/shKSAgzsxe8c\n\tnW07xjKDWoTAqAZi2fUCpVV6cXkoCQYLK5ydK1AzyEZx1fXqkpsi1B2E8HJpvhe+\n\t8wYXa25yJvc8x4GpVb0ZjyhBhD40=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender\n\t:mime-version:in-reply-to:references:from:date:message-id\n\t:subject:to:cc:content-type; s=default; bh=q/GMqNbtyruF4SSbFH5n8\n\t/KXTDE=; b=qAkKsbMpiWXSdweAN2ObHLR+agfH7miPQFPUCHbV+qmWQTvCfOcOc\n\ty/mwMRpiovFA1tjvCetyC98WPsOYrsMqhijo/s/1tzKRxIwzBCi7Gw2/1ZzRTX48\n\tPzzK5O43269lU2bqR3UtQHL39yxZIzDLkxOpqEHcR4Y+Jn94sB0gwI=","Mailing-List":"contact gcc-patches-help@gcc.gnu.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Archive":"","List-Post":"","List-Help":"","Sender":"gcc-patches-owner@gcc.gnu.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-6.6 required=5.0 tests=AWL, BAYES_00,\n\tFREEMAIL_FROM, GIT_PATCH_1, RCVD_IN_DNSWL_NONE,\n\tSPF_PASS autolearn=ham version=3.3.2 spammy=","X-HELO":"mail-vk0-f65.google.com","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net;\n\ts=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=+Y1IMadH2pUiJ6ryR3/WVOr/OKqQIejRhwjMHMQaZok=;\n\tb=ZyPDfuEL9kGaQEny110LYM33qUGBNABL35C9fOoeVaLMNiK7phV9NacRnNfEd3ZxjA\n\tLQtbNxI7IaP/O5Rr9SBmwsKd2dbKpTf1BuVb7kecItOqTDTCm9jGntjOIxwRgpAEGMIs\n\tHvuoIG1zQ34zcYovawnUD5/oB232Zkdykpsgs+QN5ERkWV26tHMJXDCGUBRbPyLJMSfZ\n\tCFwJ+cWU4r99g3yzAGdwACLSGm8jsXVgz3GMvdaUmjqwYKF9Q+1Df/gwx3AE8GybTlUF\n\t7u+3npzVX1HSLmCq2VLwdfAYb+CBa0RJPb5BPFKQUpst2TUfy8RT6uuGqy2w3fv4Sr20\n\tPjAw==","X-Gm-Message-State":"AHPjjUi+xBfIA8IL7J+QX2rpL8hHn5nQNPUbSNLlrqsLln5UwIql7DeF\ta8IU2WDnrgdih+zYSzefFGD5b0nuew==","X-Google-Smtp-Source":"ADKCNb46bxIH7ikaGzRKDz2gywSBmxuFVtlyDf8ndfEjQY/qRINRr0JbUZhC+9/qhl/rElQljiqvFHjDcX2BpxZOtJI=","X-Received":"by 10.31.34.84 with SMTP id i81mr1840731vki.66.1504613319588;\n\tTue, 05 Sep 2017 05:08:39 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"\n\t\n\t\n\t","From":"Uros Bizjak ","Date":"Tue, 5 Sep 2017 14:08:39 +0200","Message-ID":"","Subject":"Re: [PATCH,\n\tmiddle-end]: Introduce memory_blockage named insn pattern","To":"Alexander Monakov ","Cc":"\"gcc-patches@gcc.gnu.org\" ","Content-Type":"text/plain; charset=\"UTF-8\""}},{"id":1763482,"web_url":"http://patchwork.ozlabs.org/comment/1763482/","msgid":"<87lgltyuyw.fsf@linaro.org>","list_archive_url":null,"date":"2017-09-05T16:24:23","subject":"Re: [PATCH,\n\tmiddle-end]: Introduce memory_blockage named insn pattern","submitter":{"id":5450,"url":"http://patchwork.ozlabs.org/api/people/5450/","name":"Richard Sandiford","email":"richard.sandiford@linaro.org"},"content":"Uros Bizjak writes:\n> On Tue, Sep 5, 2017 at 12:35 PM, Alexander Monakov wrote:\n>> On Tue, 5 Sep 2017, Uros Bizjak wrote:\n>>> This patch allows to emit memory_blockage pattern instead of default\n>>> asm volatile as a memory blockage. This patch is needed, so targets\n>>> (e.g. x86) can define and emit more optimal memory blockage pseudo\n>>> insn.\n>>\n>> Optimal in what sense? What pattern do you intend to use on x86, and\n>> would any target be able to use the same?\n>\n> You don't have to emit a generic asm-like pattern. This is the same\n> situation as with blockage insn, where targets can emit \"blockage\"\n> instead of generic asm insn.\n>\n> x86 defines memory_blockage as:\n>\n> (define_expand \"memory_blockage\"\n> [(set (match_dup 0)\n> (unspec:BLK [(match_dup 0)] UNSPEC_MEMORY_BLOCKAGE))]\n> \"\"\n> {\n> operands[0] = gen_rtx_MEM (BLKmode, gen_rtx_SCRATCH (Pmode));\n> MEM_VOLATILE_P (operands[0]) = 1;\n> })\n>\n> However, this definition can't be generic, since unspec is used.\n\nIf all ports have switched over to define_c_enum for unspecs\n(haven't checked), we could probably define something like this\nin common.md.\n\nThanks,\nRichard","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list gcc-patches@gcc.gnu.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=gcc-patches-return-461519-incoming=patchwork.ozlabs.org@gcc.gnu.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org\n\theader.b=\"mjXG1yjj\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xmsW22QDdz9s7g\n\tfor ;\n\tWed, 6 Sep 2017 02:24:45 +1000 (AEST)","(qmail 4920 invoked by alias); 5 Sep 2017 16:24:36 -0000","(qmail 4908 invoked by uid 89); 5 Sep 2017 16:24:36 -0000","from mail-wr0-f176.google.com (HELO mail-wr0-f176.google.com)\n\t(209.85.128.176) by sourceware.org\n\t(qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP;\n\tTue, 05 Sep 2017 16:24:30 +0000","by mail-wr0-f176.google.com with SMTP id 108so9745108wra.5 for\n\t; Tue, 05 Sep 2017 09:24:29 -0700 (PDT)","from localhost ([95.145.139.63]) by smtp.gmail.com with ESMTPSA id\n\tp71sm855430wmd.40.2017.09.05.09.24.26 (version=TLS1_2\n\tcipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tTue, 05 Sep 2017 09:24:26 -0700 (PDT)"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender:from\n\t:to:cc:subject:references:date:in-reply-to:message-id\n\t:mime-version:content-type; q=dns; s=default; b=lh/zR/Ojx8ce3DN3\n\t1zPfBAez0bgO4euhuelqKFa7/J2yBtA6GchnnoV4lviOnJL8tCfNmRi9VbhThxIA\n\tT4QRSAWRbSQW+/zKKRaxc8KNROCaCdN6p6tIVeSbalXHNkUK7Er6hDpFjUVr7UCF\n\tXkEjMCELYlyzDQAu9xeH7EODsJA=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender:from\n\t:to:cc:subject:references:date:in-reply-to:message-id\n\t:mime-version:content-type; s=default; bh=clQ9DZMnMqlvqtTi5HnaFd\n\tqTHbY=; b=mjXG1yjjyHrGMlMJLwpCv4kLdRyAT9a8TcdT2rruauGks63zz1moX2\n\tN2GU7RRu++p5fYuotdUgusBbtWA2FaOWWL7j2Hmqj9jPtymGfMASOe/LHzIRfSe2\n\tPP4umFcwWwVRgOcvY/znAn00wRr6FmHYpuNr0afhF8prjtMihbCIY=","Mailing-List":"contact gcc-patches-help@gcc.gnu.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Archive":"","List-Post":"","List-Help":"","Sender":"gcc-patches-owner@gcc.gnu.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-2.6 required=5.0 tests=AWL, BAYES_00,\n\tRCVD_IN_DNSWL_NONE,\n\tSPF_PASS autolearn=ham version=3.3.2 spammy=","X-HELO":"mail-wr0-f176.google.com","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net;\n\ts=20161025;\n\th=x-gm-message-state:from:to:mail-followup-to:cc:subject:references\n\t:date:in-reply-to:message-id:user-agent:mime-version;\n\tbh=DDG6k7llwznmSaZmqRIu5/xnLSfewozr7+Yqi5n8v5U=;\n\tb=QDoI8lkDtlUBGLvxuFcBuvOQjEYVUOTOJ/GSDXrjNQZFWZ1GUUb7OaL9/3MgeZQBGM\n\t2lz9rHewXFUTyMuK7qR5eD49fZwG8lMGNXEebwnhLs/wM72uY4xDyBoSQtUrhCm8bk2j\n\t0HPWA+lXxJwyRkdd8RgHub8Sk42A9PV5XcX1faiTJgYGwDjirxaDWzMjDME8TcA+AHb0\n\tt9P6FvkiMR46vkcKNXQ8WmGVNhm055+gVdKkoZVDwfzP8QIiZpgaZkdm7D3vQP9PkI2C\n\tmJn7XzEebo+EUzstCePxo/EtvbMXGe5G44JBxI/C7R70STnMWdjFf3j1ObxiIJ1mD4S2\n\tJK/g==","X-Gm-Message-State":"AHPjjUi03qNjM4eBCYh6qHx3p6ISTYOw/uqhCNE6doBJyl12V0DDK/zt\tO+M34v4Xw9b34AXjv7KzBw==","X-Google-Smtp-Source":"ADKCNb4vmZjGLn35jmLUg1hM0UZ6Gwgi4EOWd7ArXWDfYlnWYD0sjmXTbJWRpBbjYr0wSmIzCtd75g==","X-Received":"by 10.223.130.79 with SMTP id 73mr2674538wrb.241.1504628667645;\n\tTue, 05 Sep 2017 09:24:27 -0700 (PDT)","From":"Richard Sandiford ","To":"Uros Bizjak ","Mail-Followup-To":"Uros Bizjak ,\n\tAlexander Monakov ,\n\t\"gcc-patches\\@gcc.gnu.org\" ,\n\trichard.sandiford@linaro.org","Cc":"Alexander Monakov ,\n\t\"gcc-patches\\@gcc.gnu.org\" ","Subject":"Re: [PATCH,\n\tmiddle-end]: Introduce memory_blockage named insn pattern","References":"\t\t","Date":"Tue, 05 Sep 2017 17:24:23 +0100","In-Reply-To":"\t(Uros\n\tBizjak's message of \"Tue, 5 Sep 2017 13:08:39 +0200\")","Message-ID":"<87lgltyuyw.fsf@linaro.org>","User-Agent":"Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)","MIME-Version":"1.0","Content-Type":"text/plain"}}]