From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) by sourceware.org (Postfix) with ESMTPS id ADC043858C52 for ; Mon, 29 May 2023 13:02:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ADC043858C52 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-pl1-x62f.google.com with SMTP id d9443c01a7336-1b010338d82so21170605ad.0 for ; Mon, 29 May 2023 06:02:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685365341; x=1687957341; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=MzZx94Z3usdwKYKlowwbZ6EGL2X7TzMFM/wEJlOz/W0=; b=EsqCweW8wO5qADLgNgx3Gb/qWUArKVtLjmR9KvqDBcxsMVS8hQj7jIb2coxyvkUiuD iM3imAxGOglyR2GRyrtQTL9LGsOhBb/vzH8NlYrhSSWUpBMMuww8uYqw7ZYODUeESgjK ldB1IrkUidXg1Hb7iHORYL20Vna+rqiS/TxK5hrkwJFmmyN3TI1tlux83BJeU0xgwblJ rsrDtne1jYoXjiFF0K5vqGfsebn2q6565N3U1gA6zk4QsoL5aYhVjzquku8mCO3S4+mA jCq4BiznWK9tU58F7NsIy2118WXwYNV1qwbxe8lG/gJ4ihIsCPpwBY5gX2215lFvLtIS pZaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685365341; x=1687957341; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=MzZx94Z3usdwKYKlowwbZ6EGL2X7TzMFM/wEJlOz/W0=; b=YrzbiZMvharNJ6UrxH/O+ey6hEkhQUbScWjhgIv9vH3b6h11IzrYY1hrRlWKHSIX+3 +HA7aLq7kyzMymJhNvIZlS5UipgKh9HfN2lx0b6yvaF4XaE/tteIFqM4GAZcOBxMjvK2 lDWCauEjS4bKmtfSfV6KeeIXBBYQdZBSvWjHjGIP7bIEOLQjKn0LIFB+UhCWreQmXLqN U4TXyJqsOTats9RWlkXJuinGuQxSqbjQYXKGgBRRYfAccldrQODlIMD5FR2NocGc5JKO paNVZEDiv1oR6Eg9E+IIUFVyKlSw7MzEQeeHbL/HwWa/PTx/Zvl2qFYEfECcclQWcRZl ePCg== X-Gm-Message-State: AC+VfDzKT8T6bGj4bIMxJX/IKnDNd3QUpGqnZhGqINVTMUYUArQR0pU0 U4i4BpZLEBtVRxfFkpwaJyJOUvRjW+0= X-Google-Smtp-Source: ACHHUZ5M1cmzpwgkxIFHRpj13NsjU3BSEY5hSgmSRzwqgQM5avbrmPU0r5adrqxAZdhJuWY5Te3kyA== X-Received: by 2002:a17:902:f545:b0:1aa:86a4:37ed with SMTP id h5-20020a170902f54500b001aa86a437edmr14285187plf.55.1685365340533; Mon, 29 May 2023 06:02:20 -0700 (PDT) Received: from ?IPV6:2601:681:8d00:265::f0a? ([2601:681:8d00:265::f0a]) by smtp.gmail.com with ESMTPSA id p4-20020a1709028a8400b001acae9734c0sm2915041plo.266.2023.05.29.06.02.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 29 May 2023 06:02:20 -0700 (PDT) Message-ID: Date: Mon, 29 May 2023 07:02:18 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: [PATCH] RISC-V: Add the option "-mdisable-multilib-check" to avoid multilib checks breaking the compilation. Content-Language: en-US To: Jin Ma , Kito Cheng Cc: gcc-patches , "Maciej W. Rozycki" , "richard.sandiford" , "christoph.muellner" , "jinma.contrib" References: <20230523044202.1201-1-jinma@linux.alibaba.com> <25b40604-3608-4be4-91e9-46d5ce9ccb9a.jinma@linux.alibaba.com> From: Jeff Law In-Reply-To: <25b40604-3608-4be4-91e9-46d5ce9ccb9a.jinma@linux.alibaba.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 5/28/23 21:46, Jin Ma wrote: >>>>> When testing a extension, it is often necessary for a certain program not to >>>>> need some kind of extension, such as the bitmanip extension, to evaluate the >>>>> performance or codesize of the extension. However, the current multilib rules >>>>> will report an error when it is not a superset of the MULTILIB_REQUIRED list, >>>>> which will cause the program to be unable to link normally, thus failing to >>>>> achieve the expected purpose. >>>> >>>> Hmm, I have troubles understanding what is going on here. What do you >>>> refer to by saying: "it is not a superset of the MULTILIB_REQUIRED list"? >>> >>> This is a new matching rule added by kito for the multilib of riscv: >>> https://github.com/gcc-mirror/gcc/commit/d72ca12b846a9f5c01674b280b1817876c77888f >>> >>>> There should be no problem with linking compiled modules together that >>>> make use of different extensions, with the static linker figuring out the >>>> combined set of extensions actually required at run time for the program >>>> loader to consider, as long as the modules do not have contradicting >>>> requirements, e.g. big vs little endianness or RV32 vs RV64. >>>> >>>> Can you give me a specific example (compilation options and multilibs >>>> available) of a failure you refer to? >>> >>> A simple example: >>> 1. Use "--disable-multilib --with-abi =lp64d --with-arch =rv64imafdc_zba_zbb_zbc_zbs" >>> to build the toolchain". >>> 2. Use the toolchain to test the impact of zba_zbb_zbc_zbs extensions on the >>> performance and codesize of some functions or files in the program. >>> >>> In this case, I may need to use the command "-mabi=lp64d -march=rv64imafdc" for >>> the compilation of a specific .c file in the program, which will cause the link to >>> fail and throw the following error: "FATAL ERROR: Can't find suitable multilib set for >>> '-march=rv64imafdc'/'-mabi=lp64d'". This does not satisfy the purpose of the test. >> >> I feel this case should be build with --with-arch =rv64imafdc and test >> with -march=rv64imafdc and -march=rv64imafdc_zba_zbb_zbc_zbs, >> but anyway I am OK with option :P > > Yes, but with "--with-arch=rv64imafdc" building toolchains, the library will not contain > zba_zbb_zbc_zbs extensions, so how can we quickly and easily eliminate the impact of not > using zba_zbb_zbc_zbs extensions in a certain program on program performance and codesize? > > Although-mno-multilib-check is unsafe, it is useful during the development and testing phases. But I'm not sure that's a good reason to include an unsafe option like this in the official GCC sources. This is the kind of thing that I'd tend to think belongs as a local change. jeff