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 4EC4F3858D38 for ; Thu, 23 May 2024 13:08:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4EC4F3858D38 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 4EC4F3858D38 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::435 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1716469700; cv=none; b=P/4w9B5wDwkSG1PqlUITs3GddMYVW9v2Q3r3CZW48QB1qMt8GOaX27n6AX2ADn3Zqz+agDLDm9SpEEYWGz/Sh7vwUKnpmzSsyH3/siCeEczDdXc2/Tlm5seEbiODhw6OfiGmG/6+xOq3NsHiu4N4hD4cmhZ96KQrfjHMQ5brBDI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1716469700; c=relaxed/simple; bh=jS6PwXR4uxCZRv2UuvsUmUaSZ5o1yN5J9I+x9UkCK4U=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=x19BKsCsDMcWTqr0L40E8sgr97CNJw2fjsHpfQszWIcHI/iiTZjk9Q/3xKnNeELrgCtWc+N2Lv6SiS0CTcNURyEg7YmGJSsJ9LjMa6xHwwjGppdEZt0O9mmrB2z2mXyWHq3NO/h/o/4789R9Y+e2mlG4JEeeGyAVz5jGAg9/DYU= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pf1-x435.google.com with SMTP id d2e1a72fcca58-6f43ee95078so3604649b3a.1 for ; Thu, 23 May 2024 06:08:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1716469690; x=1717074490; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=gI9m5eAcSieYoDSd8ItHfbBBm80uwmP2FXMORzyCUkY=; b=GnZ0r+lmAvIh4xSCFR0ePgaHEDGirCbWrYuG3QGxw5nAuVEDfrPpRZ/5RuerJiGAws MCw2BSkQ+zfQe3GmM8H53Cq1Kz3a8seTYR3mN1Viuye9S5P+QirGdMl/xRBSP0Bi2hsJ zTpZidi2k0knfpFfc1KbL66HVXQ5GIURA6hLqgtq5r2XDL72s9diXqHfJbEIdGd2NlbP 4wJl9wLBkjGkn1zVjJLcD16brBnqWGPiWS5RH+bhIt/R21yElLf+xESOxWyUzmoRf6tw oxPh/NgT4E6lQFIasnat7J40xBLOQyG6xSJIZq5Gdw4vuLkVn8nlg53vRBdkvnOxjuN+ TZgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716469690; x=1717074490; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=gI9m5eAcSieYoDSd8ItHfbBBm80uwmP2FXMORzyCUkY=; b=uU/MqbC1FxrDNzTWZOw/IUBFLG9jczQVjy2J1P0JaPl8v5H9ZSSCN3WOboc3mgFnkG LD1RZymFSPTo/gXQBhfSch1v1VxGIr9GeNNjUoizlAMVGdyPCCGKilHv2CR7LyCWrakz OG6AIreZLHK9LVRgHdcqA5ppEG1/V+ZF8Vzx+EtyWjEPzfJOs+GNq++g4rQtn8l8Osov T/cYUwq9c5B+lcghvjqkfbvjrtnKFed673LO+eTKwnOdRb7AnCxJdEwOSCs60pWm8L5O bljSpTJiPjOvuZD+JeYJEB0KkWMFlW9k8lSdlXMzbXg7IoExN1+k2PWIPxTHbb720NNq m15w== X-Gm-Message-State: AOJu0YztOTEt3h2KiaEpEInZoAjxNIlQk8mHWVEc0ybYyX1lgbu6czBV a5hi03S5lxfKV+2bemldGxAN1rZ6XajwrKgHyMeHSrn0evVWM+/9nbFzfPj7GS4= X-Google-Smtp-Source: AGHT+IGAfw/8BG51isqB2ZcoyliVTKDv3GQ6eZeNVrqJqUaHWEk+SRXnjPvYRMh3kCfotPzm2yLhpw== X-Received: by 2002:aa7:9307:0:b0:6f8:b262:5b15 with SMTP id d2e1a72fcca58-6f8b2625e5dmr674350b3a.11.1716469690192; Thu, 23 May 2024 06:08:10 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c3:7718:5dd8:d5e8:7ff2:a12a? ([2804:1b3:a7c3:7718:5dd8:d5e8:7ff2:a12a]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-6f696f26188sm10335919b3a.179.2024.05.23.06.08.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 May 2024 06:08:09 -0700 (PDT) Message-ID: Date: Thu, 23 May 2024 10:08:07 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/2] Aarch64: Add new memset for Qualcomm's 0ryon-1 core To: "Andrew Pinski (QUIC)" , Florian Weimer Cc: "libc-alpha@sourceware.org" References: <20240508165924.874710-1-quic_apinski@quicinc.com> <20240508165924.874710-2-quic_apinski@quicinc.com> <87ttj0vofm.fsf@oldenburg.str.redhat.com> Content-Language: en-US From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 22/05/24 20:01, Andrew Pinski (QUIC) wrote: >> -----Original Message----- >> From: Andrew Pinski (QUIC) >> Sent: Tuesday, May 14, 2024 12:41 AM >> To: Florian Weimer ; Andrew Pinski >> (QUIC) >> Cc: libc-alpha@sourceware.org >> Subject: RE: [PATCH v2 2/2] Aarch64: Add new memset for >> Qualcomm's 0ryon-1 core >> >>> -----Original Message----- >>> From: Florian Weimer >>> Sent: Tuesday, May 14, 2024 12:32 AM >>> To: Andrew Pinski (QUIC) >>> Cc: libc-alpha@sourceware.org >>> Subject: Re: [PATCH v2 2/2] Aarch64: Add new memset for >> Qualcomm's >>> 0ryon-1 core >>> >>> * Andrew Pinski: >>> >>>> +L(try_zva): >>>> + /* Write the first and last 64 byte aligned block using >> stp rather >>>> + than using DC ZVA. This is faster on some cores. >>>> + */ >>> >>> The “some cores” part seems outdated if it's just a memset >> for the >>> Oryon-1 core (singulare). This comment and some others, >> for example >> >> Will fix. >> >>> >>>> + /* >>>> + * Adjust count and bias for loop. By subtracting extra 1 >> from count, >>>> + * it is easy to use tbz instruction to check whether >> loop tailing >>>> + * count is less than 33 bytes, so as to bypass 2 >> unnecessary stps. >>>> + */ >>> >>> do not use GNU style. This one is GNU style: >> >> This was copied exactly from memset_emag.S which has the >> style issue in it too. It was in 9627ab99b50 commit where this >> comment was introduced which copied from >> memset_base64.S. >> Should we fix the other files or just the new files? Because it >> seems like having one version being based on the other once >> and then changing the style in one case but not the other >> seems wrong. >> I suspect there many more GNU comment style issues in the >> aarch64 mem* functions even. > > Ping on this question? I don't want to update my patch until I get a further clarification on if the other files should be fixed in a similar way or if it is ok having the two files have different coding styles or should we just keep them the same. > I don't care one way or the other, I will implement it either way. Though it seems like it should be up to the maintainer to fix up coding style issues of what was already there; it should not be the burden of person submitting code that is doing copying. I see these specific coding styles as non-blocking issues, my expectation would be to you fix it locally and install the patch. If you want to fix it on other files it would be good as well, but also not a requirement. My understanding was that it was not caught back when EMAG implementation were added.