From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) by sourceware.org (Postfix) with ESMTPS id 452E33858C2B; Wed, 19 Jul 2023 21:11:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 452E33858C2B Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=acm.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-qt1-x82e.google.com with SMTP id d75a77b69052e-4053cc10debso1210191cf.2; Wed, 19 Jul 2023 14:11:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689801070; x=1690405870; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=nYvTTjka3Nv/elr4AEiE2mjtCJoXMkUvEn387YbxjMw=; b=rqoWQgzx901m+R9rQBfAfrbG3nncDYr7n0txX6vRFW8zJn+qky/Y0MjjZo9sWR/BvO 26miJJ80b3lXPT2AUqKg4ezjyzN3+PeoXhjplYWpil7zofGGhBAiPv+TGlrPb+tGk1zZ EeN1FrFr6Uplf7kWRhjYWhFS8Y8ycGTi3KzxBw8K7J3HSR9AC67RKI4XzPfX8IqVqVjO UX5gY2VPl2ofWkvEp6Xi2eLc3q7JFh8uitB89umv70Fr+/FlR/Cz3a3K2PfIvYuogi3Z CsbxkpnbqzfXdrtcJa3VtJ/WhF/4Ryvkn3iQdS1oSt0bB+V+UD9tTL0jfvjWYmiuvA6W 0+xA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689801070; x=1690405870; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=nYvTTjka3Nv/elr4AEiE2mjtCJoXMkUvEn387YbxjMw=; b=IFToVuXUTve7oMkOkNgR86gXTNkFsRWakcEaAq798SNQrk0bZnLmeKFED0pJZb1pBw 1IMW2jwg6E697XBbHgIYfbCeJAWvY1bklPot4fdWVZn0nZYtfmB8yvBy7qC5F5INI6zw dTqM7LV9OexobdrPdHpdTvQOEisCp7z31VuHrvUuxZ/hbo4/ArjjLtHrHn9oaXWBy0bb 2A5ALKNQEqD5QZvRaLQtdwx4WLKHh8QBK2TYaub2QjdxDpuhYjaNgornxmlaneShEj80 KFCEJfw8j2vzk2NJnHvayOEzHEuc/Lxri+LOJEcL1mIdFRsrU0nOg6KaYusZHqiU0C9X T3XA== X-Gm-Message-State: ABy/qLbj7P+iWBUaigEcZrRT4D3xqpyW4TFj3aG9pjVhCIJQrrPcq4rz FpheyXMKG44J39JaxcuuBAQ= X-Google-Smtp-Source: APBJJlEiLgAB+2+Zgolct4/YcQo8A6k0wcgokxWc1xUHolEoPw/RVAOSPZA5+UeUjpQbIsa/xfqlmQ== X-Received: by 2002:a05:622a:14f:b0:403:a770:e851 with SMTP id v15-20020a05622a014f00b00403a770e851mr23085321qtw.22.1689801069601; Wed, 19 Jul 2023 14:11:09 -0700 (PDT) Received: from ?IPV6:2601:19c:5282:9160::1? ([2601:19c:5282:9160::1]) by smtp.googlemail.com with ESMTPSA id i1-20020ac813c1000000b00401e04c66fesm1591739qtj.37.2023.07.19.14.11.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Jul 2023 14:11:09 -0700 (PDT) Sender: Nathan Sidwell Message-ID: <80a2e5b6-0580-c3f5-cb75-c8795ebabceb@acm.org> Date: Wed, 19 Jul 2023 17:11:08 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH v5 4/5] c++modules: report imported CMI files as dependencies Content-Language: en-US To: Ben Boeckel , Jason Merrill Cc: gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org, gcc@gcc.gnu.org, brad.king@kitware.com References: <20230125210636.2960049-1-ben.boeckel@kitware.com> <20230125210636.2960049-5-ben.boeckel@kitware.com> <734eef7c-f7c3-519c-e007-cb42f8dc8a82@redhat.com> <20230623024559.GA255658@farprobe> <541367ff-25da-9745-d768-c60f235cd5bc@acm.org> <20230625163610.GC270821@farprobe> <29600358-9421-cbe3-92b6-ab77a1a715d1@redhat.com> <20230719000144.GA1034956@farprobe> From: Nathan Sidwell In-Reply-To: <20230719000144.GA1034956@farprobe> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3031.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 7/18/23 20:01, Ben Boeckel wrote: > On Tue, Jul 18, 2023 at 16:52:44 -0400, Jason Merrill wrote: >> On 6/25/23 12:36, Ben Boeckel wrote: >>> On Fri, Jun 23, 2023 at 08:12:41 -0400, Nathan Sidwell wrote: >>>> On 6/22/23 22:45, Ben Boeckel wrote: >>>>> On Thu, Jun 22, 2023 at 17:21:42 -0400, Jason Merrill wrote: >>>>>> On 1/25/23 16:06, Ben Boeckel wrote: >>>>>>> They affect the build, so report them via `-MF` mechanisms. >>>>>> >>>>>> Why isn't this covered by the existing code in preprocessed_module? >>>>> >>>>> It appears as though it is neutered in patch 3 where >>>>> `write_make_modules_deps` is used in `make_write` (or will use that name >>>> >>>> Why do you want to record the transitive modules? I would expect just noting the >>>> ones with imports directly in the TU would suffice (i.e check the 'outermost' arg) >>> >>> FWIW, only GCC has "fat" modules. MSVC and Clang both require the >>> transitive closure to be passed. The idea there is to minimize the size >>> of individual module files. >>> >>> If GCC only reads the "fat" modules, then only those should be recorded. >>> If it reads other modules, they should be recorded as well. > > For clarification, given: > > * a.cppm > ``` > export module a; > ``` > > * b.cppm > ``` > export module b; > import a; > ``` > > * use.cppm > ``` > import b; > ``` > > in a "fat" module setup, `use.cppm` only needs to be told about > `b.cmi` because it contains everything that an importer needs to know > about the `a` module (reachable types, re-exported bits, whateve > With > the "thin" modules, `a.cmi` must be specified when compiling `use.cppm` > to satisfy anything that may be required transitively (e.g., a return GCC is neither of these descriptions. a CMI does not contain the transitive closure of its imports. It contains an import table. That table lists the transitive closure of its imports (it needs that closure to do remapping), and that table contains the CMI pathnames of the direct imports. Those pathnames are absolute, if the mapper provded an absolute pathm or relative to the CMI repo. The rationale here is that if you're building a CMI, Foo, which imports a bunch of modules, those imported CMIs will have the same (relative) location in this compilation and in compilations importing Foo (why would you move them?) Note this is NOT inhibiting relocatable builds, because of the CMI repo. > Maybe I'm missing how this *actually* works in GCC as I've really only > interacted with it through the command line, but I've not needed to > mention `a.cmi` when compiling `use.cppm`. Is `a.cmi` referenced and > read through some embedded information in `b.cmi` or does `b.cmi` > include enough information to not need to read it at all? If the former, > distributed builds are going to have a problem knowing what files to > send just from the command line (I'll call this "implicit thin"). If the > latter, that is the "fat" CMI that I'm thinking of. please don't use perjorative terms like 'fat' and 'thin'. > >> But wouldn't the transitive modules be dependencies of the direct >> imports, so (re)building the direct imports would first require building >> the transitive modules anyway? Expressing the transitive closure of >> dependencies for each importer seems redundant when it can be easily >> derived from the direct dependencies of each module. > > I'm not concerned whether it is transitive or not, really. If a file is > read, it should be reported here regardless of the reason. Note that > caching mechanisms may skip actually *doing* the reading, but the > dependencies should still be reported from the cached results as-if the > real work had been performed. > > --Ben -- Nathan Sidwell