2013/11/19 Richard Biener <richard.guent...@gmail.com>: > On Mon, Nov 18, 2013 at 8:12 PM, Ilya Enkovich <enkovich....@gmail.com> wrote: >> 2013/11/18 Jeff Law <l...@redhat.com>: >>> On 11/18/13 11:27, Ilya Enkovich wrote: >>>> >>>> >>>> How does pointer passed to regular function differ from pointer passed >>>> to splitted function? How do I know then which pointer is to be passed >>>> with bounds and wchich one is not? Moreover current ABI does not allow >>>> to pass bounds with no pointer or pass bounds for some pointers in the >>>> call only. >>> >>> But I don't see any case in function splitting where we're going to want to >>> pass the pointer without the bounds. If you want the former, you're going >>> to want the latter. >> >> There are at least cases when checks are eliminated or when lots of >> pointer usages are accompanied with few checks performed earlier (e.g. >> we are working with array). In such cases splitted part may easily get >> no bounds. >> >>> >>> I really don't see why you need to do anything special here. At the most an >>> assert in the splitting code to ensure that you don't have a situation where >>> there's mixed pointers with bounds and pointers without bounds should be all >>> you need or that you passed a bounds with no associated pointer :-) >> >> It would also require generation of proper bind_bounds calls in the >> original function and arg_bounds calls in a separated part. So, >> special support is required. > > Well, only to keep proper instrumentation. I hope code still works > (doesn't trap) when optimizations "wreck" the bounds? Thus all > these patches are improving bounds propagation but are not required > for correctness? If so please postpone all of them until after the > initial support is merged. If not, please make sure BND instrumentation > works conservatively when optimizations wreck it.
All patches I sent for optimization passes are required to avoid ICEs when compiling instrumented code. Ilya > > Richard. > >>> >>> >>> Jeff
