Re: [PATCH, MPX, 2/X] Pointers Checker [16/25] Tail recursion

[Jeff Law <law at redhat dot com>]

On 11/18/13 14:03, Ilya Enkovich wrote:
> 2013/11/19 Jeff Law <law@redhat.com>:
> > On 11/18/13 12:16, Ilya Enkovich wrote:
> > > With current recursion elimination we will have:
> > >
> > > test (int *param1)
> > > {
> > > <bb1>:
> > >
> > > <bb2>:
> > >     _7 = PHI<param1(D) (bb1), _6 (bb2)>
> > >     bounds2 = __builtin_arg_bounds (_7) -- WRONG
> >
> > I wouldn't say it's wrong.  It's conservatively correct if properly
> > implemented.   Why precisely do you consider this wrong?  If your code can't
> > handle it, it really should be fixed.
>
> It is wrong because __builtin_arg_bounds is used to get bounds of
> input parameter and PHI node here is not an input parameter.
OK, now we're getting somewhere.  So we've got this odd little function 
which only works on parameters.   I can't help but feel this is a bit of 
mis-design coming back to haunt us and I wonder if we're going to see 
other instances of this kind of problem.

There's something just wrong with the semantics of __builtin_arg_bounds, 
but I'm having trouble putting my finger on it.


 Correctl
> handling of __builtin_arg_bounds in this 'wrong' example requires
> adding it a PHI node semantics based on it's arg.  For me it seems
> more complex then generating a regular PHI node for bounds and makes
> GIMPLE less readable.
But presumably you have code to merge bound information already, right? 
 You need that for PHI nodes.  Can't you use that to walk up the 
use-def chains and build the bounds information?

Or if you want to fix the tailcall stuff, you can start down that 
direction.  I don't think that'll fix the nagging concerns about the 
overall semantics of builtin_arg_bounds, but it might be enough for you 
to go forward.

jeff