From patchwork Thu Nov 9 11:44:28 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Machado X-Patchwork-Id: 836309 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-466390-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="q1Cbj87s"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3yXhD36f1Pz9t4c for ; Thu, 9 Nov 2017 22:44:51 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id; q=dns; s=default; b=lo3EQoHCzMPVLmy I1RwzwHHaZI9NSCEnDgysgjLbz01oTMuSGjuNoaPKjEyuqCy/M0ppPAoyeOuXK5t IGuUHB9AUfd+OuqvE9ywVbs2Zv6gWml2izqGR7RuC+62kMtUSSAUe0FSH+fv92IV 9jqPhOpW9TG8/EbDpTbEny41fevw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id; s=default; bh=zpnxhjl2r0UggZnZLRoCS V70AwI=; b=q1Cbj87sQpCzuNyIXYmLLFk6PGI9UiG7EDeRaYWUSXQVHxXrjV8VX 4WJeWPbp8DeixkcPMhx1cCSt+FKmg/anQGDw6g7XPuaA31PmIZifsn5gnF36PuhW 6PD3nKTHhBoY0yCAR63qZuogIwocwMaqLpKs1zwh25egOmzcBv7KuM= Received: (qmail 67041 invoked by alias); 9 Nov 2017 11:44:42 -0000 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 Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 67016 invoked by uid 89); 9 Nov 2017 11:44:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.4 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM, SPF_PASS autolearn=ham version=3.3.2 spammy=reserved X-HELO: mail-qk0-f173.google.com Received: from mail-qk0-f173.google.com (HELO mail-qk0-f173.google.com) (209.85.220.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 09 Nov 2017 11:44:39 +0000 Received: by mail-qk0-f173.google.com with SMTP id 78so7264754qkz.0 for ; Thu, 09 Nov 2017 03:44:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id; bh=PrKAKbH5dGyvqoQIkPyKHIpimtBqWm02J7OybzsP6JM=; b=StibzDt/GPSeqXWwrYgxjZuLfz5xlqY0sW39TNKu9PyD7B2DO5T915CDHg4Zv9nJX4 m1Z9mbBX65UG8Kky5N8hBzS+CTPQaDpTZ6cZD5erbf7K+ple/jR7CXyyDZYRFoVwbQAq sv66PCcCoueFa7RGDC47vtXpNCWPY1PVgAXjsIrfzyTUab3XZecvPW6c1MmiHe0UzR85 lbxAc9WgyTypOmacuVKbVvJ8NQXP6c28pBnlZYjhhLsNZ2qyL8WNHsFcbaLGpVagWiyh cWbdiPVyzi0HFGUtqPSm2395ILLdTUQag0BiF6iQw+pOPPvJXpyo4DYB7VFe2/m51wok zsHw== X-Gm-Message-State: AJaThX7yKowMcu6E2J5ah2BWWC9RWsH+AygH0QpIEZlYLJeIDXgS/2ts JF5votaG3Aaahb1j1AdWwqvwWwQBQhQ= X-Google-Smtp-Source: AGs4zMZaTOYn5xu35mFzy2XM4IsxDPpMinh/fuc7sfjGvkXNY40wfJ83caFVXTAOqlhvr3AWHc6ozg== X-Received: by 10.55.215.67 with SMTP id m64mr249592qki.91.1510227877724; Thu, 09 Nov 2017 03:44:37 -0800 (PST) Received: from localhost.localdomain ([179.154.140.131]) by smtp.gmail.com with ESMTPSA id n44sm4501314qtb.41.2017.11.09.03.44.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 09 Nov 2017 03:44:36 -0800 (PST) From: Luis Machado To: gcc-patches@gcc.gnu.org Subject: [PATCH,doc] Fix latency in pipeline description example Date: Thu, 9 Nov 2017 09:44:28 -0200 Message-Id: <1510227868-31564-1-git-send-email-luis.machado@linaro.org> X-IsSubscribed: yes While reading through section 16.19.9 of the internals manual, i ran into this example that looked slightly odd: (define_insn_reservation "div" 8 (eq_attr "type" "div") "i1_pipeline, div*7, div + (port0 | port1)") Am i missing something or is this example incorrect and this should either have a latency of 9 (patch attached) or a different resource utilization description, say, containing "div*6" instead? Regards, Luis 2017-11-09 Luis Machado PR tree-optimization/82669 diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi index c4c1138..9806b65 100644 --- a/gcc/doc/md.texi +++ b/gcc/doc/md.texi @@ -9617,7 +9617,7 @@ their result is ready in two cycles. The simple integer insns are issued into the first pipeline unless it is reserved, otherwise they are issued into the second pipeline. Integer division and multiplication insns can be executed only in the second integer -pipeline and their results are ready correspondingly in 8 and 4 +pipeline and their results are ready correspondingly in 9 and 4 cycles. The integer division is not pipelined, i.e.@: the subsequent integer division insn can not be issued until the current division insn finished. Floating point insns are fully pipelined and their @@ -9634,7 +9634,7 @@ incurred. To describe all of this we could specify (define_insn_reservation "mult" 4 (eq_attr "type" "mult") "i1_pipeline, nothing*2, (port0 | port1)") -(define_insn_reservation "div" 8 (eq_attr "type" "div") +(define_insn_reservation "div" 9 (eq_attr "type" "div") "i1_pipeline, div*7, div + (port0 | port1)") (define_insn_reservation "float" 3 (eq_attr "type" "float")