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] PR middle-end/19874: TweakSTRIP_USELESS_TYPE_CONVERSION


On Thu, 2005-02-24 at 21:30 -0700, Roger Sayle wrote:
> The following patch is my proposed change to resolve PR middle-end/19874
> which is an ICE-on-valid regression on mainline caused by emit_move_insn
> being passed incompatible modes for source and destination.  The problem,
> analaysed by Jakub Jelinek was that STRIP_USELESS_TYPE_CONVERSION was
> stripping a mode changing conversion due to lang_hooks.types_compatible_p
> for the C/C++ front-ends claiming that two types were compatible as they
> have the same TYPE_MAIN_VARIANT.
> 
> Jakub's suggested fix, described in the bugzilla PR, was to tweak the
> handle_mode_attribute function in c-common.c and comptypes function in
> c-typeck.c, to change "types_compatible_p", which unfortunately breaks
> the C++ front-end.
> 
> The alternate solution below is to tweak tree_ssa_useless_type_conversion
> such that no conversion that changes the mode of it's operand is
> considered "useless".  This intuitive approach also simplifies the code
> in that function, which guarantees the modes match in every case except
> for the front-end's notion of type compatability.  Indeed, I'm not sure
> the front-end's type system should be affecting the optimizations
> performed at this point in tree-ssa.
> 
> This approach is probably contentious, so I'll check with folks whether
> they feel this fix is too conservative and potentially misses useful
> optimizations.
> 
> 
> The following patch has been tested on i686-pc-linux-gnu with a full "make
> bootstrap", all default languages, and regression tested with a top-level
> "make -k check" with no new failures.  Jakub's testcase passes with this
> patch but fails without it.
> 
> Ok for mainline?
A conversion between types with different underlying modes definitely
is not useless.  I thought we were explicitly checking for that at one
time, either my memory is failing or we lost those explicit checks.

Regardless of what's happened in the past, I absolutely agree with
explicitly rejecting any type conversion with different modes.

jeff



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