Re: [PATCH] handle bzero/bcopy in DSE and aliasing (PR 80933, 80934)

[Richard Biener <richard.guenther@gmail.com>]

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.

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.