OpenE2K/gcc
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

path solver: Prefer range_of_expr instead of range_on_edge.

Browse Source 
The range_of_expr method provides better caching than range_on_edge.
If we have a statement, we can just it and avoid the range_on_edge
dance.  Plus we can use all the range_of_expr fanciness.

Tested on x86-64 and ppc64le Linux with the usual regstrap.  I also
verified that the before and after number of threads was the same or
greater in a suite of .ii files from a bootstrap.

gcc/ChangeLog:

	PR tree-optimization/102943
	* gimple-range-path.cc (path_range_query::range_on_path_entry):
	Prefer range_of_expr unless there are no statements in the BB.
This commit is contained in:
Aldy Hernandez 2021-11-04 12:37:16 +01:00
parent e441162269
commit 6a9678f0b3
1 changed files with 16 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
gcc/gimple-range-path.cc
View File

@ -135,10 +135,24 @@ void
path_range_query::range_on_path_entry (irange &r, tree name)
{
gcc_checking_assert (defined_outside_path (name));
int_range_max tmp;
basic_block entry = entry_bb ();
bool changed = false;
// Prefer to use range_of_expr if we have a statement to look at,
// since it has better caching than range_on_edge.
gimple *last = last_stmt (entry);
if (last)
{
if (m_ranger.range_of_expr (r, name, last))
return;
gcc_unreachable ();
}
// If we have no statement, look at all the incoming ranges to the
// block. This can happen when we're querying a block with only an
// outgoing edge (no statement but the fall through edge), but for
// which we can determine a range on entry to the block.
int_range_max tmp;
bool changed = false;
r.set_undefined ();
for (unsigned i = 0; i < EDGE_COUNT (entry->preds); ++i)
{