On Fri, Jul 19, 2019 at 7:04 PM Jeff Law <l...@redhat.com> wrote: > > > While looking at BZ 80576 I realized a few things. > > First for STRNCPY we know the exact count of bytes written and we can > treat it just like MEMCPY and others, both in terms of removing/trimming > them and in terms of using them to allow removal of other stores. > > This patch adds support for those routines in DSE. We test that > subsequent statements can make those calls dead and vice versa and that > we can trim from the head or tail appropriately. > > While writing that code I also stumbled over a blob of code that I think > I copied from tree-ssa-alias.c that isn't necessary. In the relevant > code the byte count is always found in the same place. There's no need > to check the number of operands to the call to figure out where the > count would be. So that little blob of code is simplified ever so slightly. > > Finally, while writing the tests for strncpy I stumbled over a case that > we're still not handling well. > > In particular something like this: > > > > void h (char *s) > { > extern char a[8]; > __builtin_memset (a, 0, sizeof a); > __builtin_strncpy (a, s, sizeof a); > frob (a); > } > > In this case ref_maybe_used_by_stmt_p returns true for the "a" array at > the strncpy call. AFAICT that appears to happen because "a" and "s" > could alias each other. > > strncpy is documented as not allowing overlap between the source and > destination objects. So in theory we could consider them not aliasing > for this call. I haven't implemented this, but I've got some ideas > here.
But it does allow things like strncpy (&a[0], &a[n+1], n) for example? I think this kind of specialities should be handled in ref_maybe_used_by_call_p_1 directly, but I'm not exactly sure how - it's probably another case of a missing must-alias query, with that we could do /* If REF overlaps with the strncpy destination then the source argument may not alias it. */ if (refs_must_alias_p (ref_for_strncpy_dest, ref)) return false; hmm, OTOH for REF covering &a[n/2] to &a[3*n/2] (half overlapping source and destination) and the above strncpy we have a must-alias (not kill!) of REF but also are using it. So it's not so easy and would cover only very specific cases. > Anyway, I've included an xfailed test for this case in this patch. > > Bootstrapped and regression tested on x86_64, ppc64, ppc64le, aarch64 & > sparc64. Installing on the trunk momentarily. > > We could in theory handle stpncpy too, we just have to be more careful > with its return value. > > Jeff