This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] handle bzero/bcopy in DSE and aliasing (PR 80933, 80934)
On 7 June 2017 16:46:53 CEST, Martin Sebor <msebor@gmail.com> wrote:
>On 06/07/2017 02:23 AM, Richard Biener wrote:
>> On Wed, Jun 7, 2017 at 5:26 AM, Martin Sebor <msebor@gmail.com>
>wrote:
>>>> Note I'd be _much_ more sympathetic to simply canonicalizing all of
>>>> bzero and bcopy
>>>> to memset / memmove and be done with all the above complexity.
>>>
>>>
>>> Attached is an updated patch along these lines. Please let me
>>> know if it matches your expectations.
>>
>> I think you attached the wrong patch.
>
>Yes I did, sorry. The correct one is attached.
Under POSIX.1-2008 "optimizing" bzero or bcmp is IMO plain wrong.
It's like optimizing foo() to a random built-in but maybe that's just me. If your libc provides a define to a standard function for these under a compat knob then fine but otherwise you should fix that. *shrug*. Joseph?
thanks,
>
>Martin
>
>>
>> Richard.
>>
>>> FWIW, although I don't feel too strongly about bzero et al. I'm
>>> not sure that this approach is the right one in general. It might
>>> (slightly) simplify GCC itself, but other than the incidental code
>>> generation improvement, it offers no benefit to users. In some
>>> cases, it even degrades user experience by causing GCC issue
>>> diagnostics that refer to functions that don't appear in the source
>>> code, such as for:
>>>
>>> char d[1];
>>>
>>> void* f (const void *p)
>>> {
>>> bzero (d, 7);
>>> }
>>>
>>> warning: ‘__builtin_memset’ writing 7 bytes into a region of size
>1
>>> overflows the destination [-Wstringop-overflow=]
>>>
>>> For some functions like mempcpy it might even worse code overall
>>> (slower and bigger).
>>>
>>> In other cases (like profiling) it loses interesting information.
>>>
>>> I think these types of transformations would be justified f they
>>> were done based on measurably improved efficiency of the generated
>>> code, but I'm uneasy about swapping calls to one function for
>another
>>> solely because it simplifies the implementation. Not least because
>>> it doesn't seem like a viable general approach to simplifying the
>>> implementation.
>>>
>>> Martin
>>>
>>> PS I stopped short of simplifying GCC to remove the existing special
>>> handling of these three built-ins. If the patch is approved I'm
>>> willing to do the cleanup in a subsequent pass.