https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125986

--- Comment #2 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Created attachment 64853
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=64853&action=edit
proof of concept for querying the path oracle for SSA relations

In an email, Andrew mentioned that the correct way to approach this was to ask
the path oracle to resolve the relation in question, and it would in turn ask
the root oracle if it couldn't resolve the relation within the path.

For the record, we already register relations *along* the path with
path_range_query::compute_outgoing_relations().  What this patch does is query
the path oracle for SSA relations in hopes the path oracle will resolve things
outside of the path.

However, even with this patch, we don't seem to resolve things outside of the
path because of:

relation_kind
path_oracle::query (basic_block bb, const_bitmap b1, const_bitmap b2)
{
...
  // Do not look at the root oracle for names that have been killed
  // along the path.
  if (bitmap_intersect_p (m_killed_defs, b1)
      || bitmap_intersect_p (m_killed_defs, b2))
    return k;
...

We don't look at the root oracle because we have a killing def of _155 which is
in the equivalence set of _374:

(gdb) print ::debug(m_killed_defs)
155
(gdb) print ::debug(b2)
155, 374

And the reason we have this killing def, is that _155 is set as an equivalence
along the path, because it is a PHI.

<bb 57> [local count: 1015094502]:
  # ip_155 = PHI <prephitmp_374(52), ip_210(56), ip_210(55)>

Remember the path is 52->57, so ip_155 is _374, which kills the def along the
path, thus causing the query() to avoid looking at the root oracle.  Also, the
statement which has the relation we are trying to resolve is:

(gdb) p ::debug(stmt)
if (_238 > prephitmp_374)

Let me know if there's anything else I can do to help.

Reply via email to