This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] ieee754/dbl-64: Reduce the scope of temporary storage variables
- From: Vineet Gupta <Vineet dot Gupta1 at synopsys dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, "linux-snps-arc at lists dot infradead dot org" <linux-snps-arc at lists dot infradead dot org>
- Date: Mon, 11 Nov 2019 22:43:59 +0000
- Subject: Re: [PATCH] ieee754/dbl-64: Reduce the scope of temporary storage variables
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=synopsys.com; dmarc=pass action=none header.from=synopsys.com; dkim=pass header.d=synopsys.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W/3gN8OmOmrOafnVYnSzcRIXqdHgmcL5w+CaDrXEB1E=; b=hGM1ySA6QwUhL2YV6J+K3Ae6Ck5XtzbIh6RQ0JMoR+RsCTwX/cRCihbQDEGNpHUGQ5xMoOIm3fO7+FxWeYWzAnIEL5JzGaSiiwr7k9NBGxqdQUPOWP6UYKXEEmFXnD9cxknDmS4tnv7QJfJ8D59TbKXqJ4LWBbNiaPXOh55bvDdA+mxsrWreu5GHBMUyhnGSEt6WdHBpeQscGHtXbRrP1GZpR68j/xG4EAufT16Ic0WeAF+OH5rcTnMc41ExyefwQk3ZdRc3yuTuq8vUDW0U1LDhOXkwYOMfVrbINEYpLSd6wbE3zucOxcrsTyghwNc5l4wTEvKp62X8JT//JiuTFw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ggVisumRzkof+1ouM/liQepZrqpbhW6RHVioYAZRKKDPflMAsYITOxjDRS50AnuEnT+cfWXr3VMYIwGFo8UA9iJvF0epKZtT59Hao5JqdptaiRFtY0B5rdsRchPkFu5BDYkJHQrfMm6RdDah7ITfakuePbzrRCRw20C5H5KDfj+X9yYCjY+xQ6orLnQdB9zuu3rOHcjvnrNJPpfZQILMV9iZRApDSjuxjk6/XGHAr3Wf0e4eN9lK0kyfWVRqv+NqdS79RyutufTES4USq28mUtbKwoPp1DLqlUdxCa6XFM3bD0aCbRh+qpkK+UMjeWBymkjqpYAzTsRE0oklBkR+OA==
- References: <20191111194349.21813-1-vgupta@synopsys.com> <alpine.DEB.2.21.1911112228550.30786@digraph.polyomino.org.uk>
On 11/11/19 2:33 PM, Joseph Myers wrote:
> On Mon, 11 Nov 2019, Vineet Gupta wrote:
>
>> Functionally it should not result in code gen changes and if at all
>> those would be better since the scope of those temporaries is greatly
>> reduced now
> This feels like the sort of thing where "should not result in code gen
> changes" should be tested by running build-many-glibcs.py --strip with
> unmodified glibc sources to build a full set of stripped glibc binaries,
> saving those binaries and then running build-many-glibcs.py --strip again
> and comparing the two sets of shared libraries (something I did a lot of
> when reworking how libm function aliases were defined; static libraries
> are expected to change because of timestamps, but shared library binaries
> can be usefully compared like this). If the two sets of stripped binaries
> are indeed identical, that is strong evidence that the patch is safe;
> otherwise, review of the patch will require more detailed inspection of
> the types of the arguments to these macros, and the uses of the temporary
> variables, at every call site, to make sure that semantics aren't being
> changed.
Ok Understand. What arch(es) / build options would you want this tested for in
aforementioned way to get a reasonable confidence ?
> (In any case, please specify when submitting a patch how it was tested.)
I've currently tested this with build-many-glibcs.py for ARC port only with and
w/o hard float support being worked on.