This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Decrease # of update_stmt calls from alias analysis


Hello,

> > huh? No benefit??? I thought the reduction of number of update_stmt
> > calls is self-explanatory, but just to make it clear -- this patch
> > improves compile time measurably, for example by almost 1% on combine.i at
> > -O2.
> > 
> And why didn't you include this information in your report?  The fact
> that you reduce the number of calls to a certain function may be
> irrelevant in the grand scheme of things.  You really have to spell
> things out in more detail in your analysis.
> 
> > Given that the point of the patch is to avoid need to scan the
> > statement, this does not seem like a good solution to me.
> > 
> stmt_references_memory_p does not scan the statement.  However, it will
> notice zero memory operands before the first alias pass.
> 
> The simple fix is to remove this circular dependency.  Modify the
> function to directly examine the statement.  Notice that, structurally,
> it is not hard to tell whether a GIMPLE statement will reference memory:
>
> 1- Assignments.
> 2- Call sites.
> 3- ASMs
> 
> A predicate along these lines should work (may need more tweaking):
> 
> 1- TREE_CODE (stmt) == MODIFY_EXPR
>    && (TREE_CODE_CLASS (lhs) == tcc_reference
>        || TREE_CODE_CLASS (rhs) == tcc_reference)
> 
> 2- get_call_expr_in != NULL
> 
> 3- TREE_CODE (stmt) == ASM_EXPR
> 
> No other statement should be allowed to memory loads/stores.

this is a bit pessimistic (even in some of the cases you mention we
won't have vops); but that would not be that much of a problem.
Nevertheless, this needs to traverse trees, which is slow if they are
not already in cache (and given that the modify_stmt call is run in a
cycle over whole function, they will almost never be if the function is
large enough).

I do not understand why you prefer creating yet another code duplication
to straightforward updating of a single bit -- the basic purpose of
tree-ssa-operands is to precompute and cache this type of information,
so that the rest of code does not need to care about traversing trees,
so why not use it that way?

Zdenek


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]