On Wed, Dec 11, 2013 at 04:31:55PM +0800, Bin.Cheng wrote:
> Thank both of you for being patient on this patch.
> I went through the documentation quickly and realized that I have to
> modify pointer-map structure to make it recognized by GC (maybe more
Changing pointer_map at this point is IMHO not appropriate.
> work suggested by Jakub). It seems I shouldn't include that task in
> this patch at this stage 3, I am thinking just call free_affine*
> function in the place it is created for SCEV. Of course, that makes
> it more expensive.
Perhaps you could call free_affine_expand_cache say from
analyze_scalar_evolution, that is the innermost enclosing exported
API that indirectly calls your new code, but it seems it is also called
recursively from analyze_scalar_evolution_1 or functions it calls.
So maybe you'd need to rename analyze_scalar_evolution to
analyze_scalar_evolution_2 and adjust some calls to analyze_scalar_evolution
to the latter in tree-scalar-evolution.c, and add analyze_scalar_evolution
wrapper that calls analyze_scalar_evolution_2 and free_affine_expand_cache.
Whether this would work depends on detailed analysis of the
tree-scalar-evolution.c callgraph, there are tons of functions, most of
them static, and the question is if there is a single non-static (or at most
a few of them) function that cover all calls to your new code in the
static functions it (indirectly) calls, i.e. if there isn't any other
external entry point that might call your new code without doing
free_affine_expand_cache afterwards.
If you can find that, I'd say it would be the safest thing to do.
But let's see what say Richard thinks about it too.
Jakub
