From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) by sourceware.org (Postfix) with ESMTPS id 325B0384D153; Thu, 20 Oct 2022 17:37:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 325B0384D153 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pf1-x435.google.com with SMTP id 67so187270pfz.12; Thu, 20 Oct 2022 10:37:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=B73d1LcN2KDagmuGqL4/jseqlMn8RbNylfYP0c4ncXc=; b=XIhBT3zW3k8bT449ZV15FD3Z/pAWnkFOlohghUfyPGG1PChj17q5EZ118rmaE8q89Q ZHaOTVoBhpPaoUPoEsL5LX+IovaqgZDLxdO7S5c9V9b2YEWHxZousztuYYtJaEbtwFDY Y0Z6UE1bzgQ3MWODxKa97TcQpONicpdm+Z/YuwZHwlxBpD+xnNfHRnM27ZZj9X+bYbLz IjU7JS0Fkp4LVVfZSzBXp0KF5A6NkbiylDqBUJ32N2zr7BLJLAprlPyvQJqXBsp6Wyh5 xgYFpbEQCIattUKrqISIrnivgRMpUL9oRZYI6X58u14Wb0LPa5DQYangCn6hm8mZk1kJ qIKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=B73d1LcN2KDagmuGqL4/jseqlMn8RbNylfYP0c4ncXc=; b=xVo8t4JD/F166+L26qNwSE+ugKJw3OQFEpKskm5H4VlwoGfpe2bxxrqkKAzkilZP5+ GRazPlsxCDcZQ6yF6vsiLKQwDoMNf4tvy95ugdAFPS4Ih9RniRoCQPJZzpevJRNcTjXF ALC6jZNYmSMK1crUwMZzfEZnYS57Z88KhDyQdftkkk3uc4oXzVlwwV8/1xXXnnAwanF4 tTj5UI1+GCj5U1aIBUPNhect+IMn651ToXxtOLGzzbGQFClBQpXbGsTv5SVa9DZoNdFa Rdxu9R3SnfJnD++3T08SiyKI+f8I0I/d/he+Yx0+iUdxrQaZaOuxSacff8jEuSI0vJcj 3+pg== X-Gm-Message-State: ACrzQf1Ly2W97/EU9SoSUw5ZTSeudqD8VuKgCunWH1+VIan2anVcec8P eXFwnmsAyspVwfqv1U0SqBXekDKtVoroMECoQjI= X-Google-Smtp-Source: AMsMyM5AOH94nZD9oI/jPxZvjGP+ZDVYXxIJI/5flO/7r0YUhlHO0Jh6ZZvl/DwnU6MtImZZ2Nyq/6c76XlGWmQc908= X-Received: by 2002:a63:8841:0:b0:461:24b7:a621 with SMTP id l62-20020a638841000000b0046124b7a621mr12883163pgd.277.1666287460943; Thu, 20 Oct 2022 10:37:40 -0700 (PDT) MIME-Version: 1.0 References: <20221014083406.8406-1-haochen.jiang@intel.com> <20221014083406.8406-2-haochen.jiang@intel.com> <20221019211421.GQ25951@gate.crashing.org> <20221020172558.GS25951@gate.crashing.org> In-Reply-To: <20221020172558.GS25951@gate.crashing.org> From: Andrew Pinski Date: Thu, 20 Oct 2022 10:37:25 -0700 Message-ID: Subject: Re: [PATCH 1/2] Add a parameter for the builtin function of prefetch to align with LLVM To: Segher Boessenkool Cc: "Jiang, Haochen" , "gcc-patches@gcc.gnu.org" , "aoliva@gcc.gnu.org" , "richard.sandiford@arm.com" , "uweigand@de.ibm.com" , "linkw@gcc.gnu.org" , "gnu@amylaar.uk" , "dje.gcc@gmail.com" , "olegendo@gcc.gnu.org" , "claziss@synopsys.com" , "mfortune@gmail.com" , "davem@redhat.com" , "dave.anglin@bell.net" , "hubicka@ucw.cz" , "richard.earnshaw@arm.com" , "rguenther@suse.de" , "marcus.shawcroft@arm.com" , "ramana.radhakrishnan@arm.com" , "Liu, Hongtao" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham 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 Thu, Oct 20, 2022 at 10:28 AM Segher Boessenkool wrote: > > On Thu, Oct 20, 2022 at 01:44:15AM +0000, Jiang, Haochen wrote: > > Maybe the testcase change cause some misunderstanding and concern. > > > > Actually, the patch did not disrupt the previous builtins, as the builtin_prefetch > > uses vargs. I set the default value of the new parameter as data prefetch, which > > means that if we are not using the fourth parameter, just like how we use > > prefetch previously, it is still what it is. > > I still think it is a mistake to have one builtin do two very distinct > operations, only very superficially related. Instruction fetch and data > demand loads are almosty entirely unrelated, and so is the prefetch > machinery for them, on all machines I am familiar with. On aarch64 (armv8), it is actually the same instruction: PRFM. It might be the only one which is that way though. It even allows to specify the level for the instruction prefetch too (which is actually useful for say OcteonTX2 which has an interesting cache hierarchy). Though I agree it is a mistake to have one builtin which handles both data and instruction prefetch. Thanks, Andrew > Which makes > sense anyway, since instruction prefetch and data prefetch have > completely different performance characteristics and considerations. > Maybe if you start with the mistake of having unified L1 caches it > seems natural, but thankfully most machines do not do that. > > > Segher