[PATCH, MPX, 2/X] Pointers Checker [16/25] Tail recursion
Jeff Law
law@redhat.com
Tue Nov 19 20:59:00 GMT 2013
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
More information about the Gcc-patches
mailing list