[Bug middle-end/89725] ICE in get_fnname_from_decl, at varasm.c:1723

amker at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Fri Mar 29 03:56:00 GMT 2019


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

--- Comment #6 from bin cheng <amker at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #4)
> I think the issue is that the DDR is bogus - loop interchange computes
> data-refs
> for a deeper nest (including some outer loops) than it ends up doing
> dependence checking later on.  But we have access functions analyzed with
> respect to outer loops already.
> 
> I think it would be possible to handle this in data dependence computation,
> simply treating evolutions in outer loops as invariants.  Eventually the
> access functions evolving in outer loops can also be pruned?  We can't
> really undo SCEV analysis on them.
> 
> I think that Jakubs fix is too conservative though.
> 
> Since we fail when we cannot compute the "invalid" subscript distance at the
> moment the safest fix would probably to create the DDR with the loop-nest
> we originally analyzed?  Bin?
Unfortunately No.  The access functions are analyzed wrto outer loops in order
to cache find-data-reference process, thus save compilation time.  Actually, we
end up with computing ddr wrto deeper loop_nest here because computation with
the originally analyzed loop_nest has failed.  So this change won't do anything
other than compute the same DDRs twice (and both would fail).

There may be couple ways out.
1. Cancel the data reference caching by collecting DRs for loop_nest.  At this
stage, this might be the safest fix but very expensive.
2. Fix the DDR analysis code.  For example as you suggested, or maybe we can
simply bypass the irrelevant part when computing dir/dist vector?
3. Note we already prune_data_refs_not_in_loop, we can also prune the access
functions too.  Not sure if this is feasible.  Also not sure if it's useful
enough to be exposed as an tree-data-ref.h interface.  Will have a check.


> diff --git a/gcc/tree-data-ref.h b/gcc/tree-data-ref.h
> index 11aa806a64d..54651e903ff 100644
> --- a/gcc/tree-data-ref.h
> +++ b/gcc/tree-data-ref.h
> @@ -585,6 +585,7 @@ index_in_loop_nest (int var, vec<loop_p> loop_nest)
>      if (loopi->num == var)
>        break;
>  
> +  gcc_assert (var_index < loop_nest.length ());
>    return var_index;
>  }
Guess this code should be included anyway, right?

Thanks


More information about the Gcc-bugs mailing list