[Ada] Reorganize max_size implementation

[Roger Sayle <roger at eyesopen dot com>]

The following patch is a reorganization of the gnat front-end's
max_size function.  I intend to move some constant folding
transformations from fold-const.c into max_size, and to simplify
the task of reviewing that I'm submitting this clean-up first
which should have no functionality changes.

Currently, max_size is structured as a switch on TREE_CODE_CLASS,
and within each case the code typically checks for two or three
specific tree codes, and then provides a default implementation
for that class.  This means that processing of MINUS_EXPR, for
example, is deeply indented and painful to modify amidst lots of
other processing.

The proposed clean-up is to restructure this function into two
switch statements.  The first by TREE_CODE contains all of the
special case processing per TREE_CODE, and the second reachable via
the default of the first, then contains the generic implementations.

An analysis of the 73324 calls to max_size during an Ada bootstrap
and ACATs run reveals the following distribution of calls to max_size.

  23832 integer_cst c
  14349 nop_expr 1
   8727 non_lvalue_expr 1
   5942 mult_expr 2
   5673 max_expr 2
   5354 component_ref r
   4119 plus_expr 2
   1456 ceil_div_expr 2
   1268 minus_expr 2
   1025 cond_expr e
    823 var_decl d
    756 min_expr 2

Clearly also handling INTEGER_CST and NOP_EXPR in the first switch
should help performance (not that this is an issue :).


I've attached two versions of this patch, one against mainline and the
other against the tree-ssa-pre-merge tag.  Changes in the number of
operands of CALL_EXPR mean that a single patch doesn't apply cleanly
in both cases.

The following patch has been tested against tree-ssa-pre-merge with
a full bootstrap, including Ada, and regression tested with a top-level
"make -k check" with no ACATS failures.

Ok for mainline and/or ACT CVS?


2004-05-18  Roger Sayle  <roger@eyesopen.com>

	* utils.c (max_size): Reorganize to process individual TREE_CODEs
	in one switch, then generic implementations per class in a second.


Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833

Attachment: premerge.txt
Description: Text document

Attachment: mainline.txt
Description: Text document