This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] Get rid of awkward semantics for subtypes
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Eric Botcazou <ebotcazou at adacore dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 6 May 2009 20:53:35 +0200
- Subject: Re: [RFC] Get rid of awkward semantics for subtypes
- References: <firstname.lastname@example.org>
On Fri, Apr 10, 2009 at 12:03 AM, Eric Botcazou <email@example.com> wrote:
> we're almost ready to get rid of the awkward semantics that is implemented in
> the middle-end and the optimizers for subtypes (INTEGER_TYPEs with a non-null
> TREE_TYPE); this should overall simplify things, make the support for invalid
> values in Ada more robust and expose more optimization opportunities.
> Patches have already been written and tested (I've attached the non-gigi part
> we currently use, preparatory patches are required for gigi first). ?All the
> subtypes are given maximal bounds for their precision, except for TYPE_DOMAIN
> of array types like in C, and thus become first class citizens. ?This makes
> it possible to eliminate code in gigi, the gimplifier, the loop optimizer,
> the VRP pass, etc. needed to specifically support their special semantics.
> This in turn means that the gimplification will eliminate most of the casts
> between subtypes and base types, making the optimizers more effective. ?The
> exception will be the VRP pass, most notably when checks are off in Ada, so
> we'll need to be able to drive VRP differently from gigi.
> Comments/suggestions welcome.
> ? ? ? ?* fold-const.c (fold_truth_not_expr) <CONVERT_EXPR>: Do not strip
> ? ? ? ?it if the destination type is boolean.
> ? ? ? ?* tree-chrec.c (avoid_arithmetics_in_type_p): Delete.
> ? ? ? ?(convert_affine_scev): Remove call to above function.
> ? ? ? ?(chrec_convert_aggressive): Likewise.
> ? ? ? ?* tree-scalar-evolution.c (follow_ssa_edge_expr) <PLUS_EXPR>:
> ? ? ? ?Propagate the type of the first operand.
> ? ? ? ?(follow_ssa_edge_in_rhs) <GIMPLE_BINARY_RHS>: Likewise
> ? ? ? ?* tree-ssa.c (useless_type_conversion_p_1): Do not specifically return
> ? ? ? ?false for conversions involving subtypes.
> ? ? ? ?* tree-vrp.c (vrp_val_max): Do not get to the base type.
> ? ? ? ?(vrp_val_min): Likewise.
> ? ? ? ?(needs_overflow_infinity): Do not special-case subtypes.
> ? ? ? ?(extract_range_from_unary_expr): Do not use the base types.
What is missing to go forward with this plan? I am hitting type consistency
problems again while trying to fix PR39999 ... :/