https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68576
--- Comment #7 from majun <majun4950646 at 163 dot com> --- (In reply to bin.cheng from comment #5) > The type conversion comses from lim, below code: > /* In case this is a stmt that is not unconditionally executed > when the target loop header is executed and the stmt may > invoke undefined integer or pointer overflow rewrite it to > unsigned arithmetic. */ > if (is_gimple_assign (stmt) > && INTEGRAL_TYPE_P (TREE_TYPE (gimple_assign_lhs (stmt))) > && TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (gimple_assign_lhs (stmt))) > && arith_code_with_undefined_signed_overflow > (gimple_assign_rhs_code (stmt)) > && (!ALWAYS_EXECUTED_IN (bb) > || !(ALWAYS_EXECUTED_IN (bb) == level > || flow_loop_nested_p (ALWAYS_EXECUTED_IN (bb), level)))) > gsi_insert_seq_on_edge (e, rewrite_to_defined_overflow (stmt)); > > Once it's introduced, SCEV can't resolve it but assume possible overflow. > > By mannually disabling lim pass, SCEV works as expected and now outer loop > can be parallelized. so,it seems better to avoid integer(kind=8) --> unsigned long --> integer(kind=8) instead of changing scev. and thanks for digging into this problem!
