Re: Value Range Propagation Patch (Version 4)

[John Wehle <john at feith dot com>]

> Did my suggestion about zero-extended variables on Alpha have any merit,
> or was it just a complete miss ?

The zero-extended variables wasn't confusing VRP (in the sense that the
wrong ranges were computed), however they did obscure things.  Given:

(insn 35 33 36 (set (subreg:DI (reg:SI 76) 0)
        (reg:DI 77)) 204 {reload_inqi_help-1} (nil)
    (nil))

(insn 36 35 38 (set (reg:DI 78)
        (zero_extend:DI (reg:SI 76))) 36 {zero_extendsidi2} (nil)
    (nil))

(insn 38 36 39 (set (reg:DI 79)
        (leu:DI (reg:DI 78)
            (const_int 9 [0x9]))) 126 {*setcc_internal} (nil)
    (nil))

(jump_insn 39 38 232 (set (pc)
        (if_then_else (ne (reg:DI 79)
                (const_int 0 [0x0]))
            (label_ref 64)
            (pc))) 151 {umaxhi3+3} (nil)
    (nil))

VRP realized that (reg:DI 78) must be <= 9 if the jump was taken.  However
version 3 didn't propagate that information backwards, as a result VRP
didn't know that (reg:DI 77) must be <= 9 which prevented the later
comparisons from being removed.  VRP version 4 performs limited back
propagation.

> How do you get it to focus its efforts on code that really matters ?

Supply simple testcases and I'll see what I can do to improve things.
There may be some heuristics which can be used to determine when to
apply VRP that someone can suggest.

> PS: Unfortunately, due to the large memory requirements, some of my
>     compilations ended with a Segmentation Fault.  I'll retry shortly
>     with only one compilation thread instead of four.

In value_range_prop is:

          /* Check for excessive memory consumption.  */
          if (max_bb_reg_vr_allocated > 100000)

which limits the number of register value ranges to 100000 (really to
200000 since the values computed in the previous iteration are around).
On the Alpha each entry is 400 bytes so memory usage should be limited
to 80 MB,  The check is after each basic block is processed ... it may
be necessary to perform the check more often.  Feel free to lower the
number to see if that helps avoid running out of memory.

The memory usage and runtime should improve if I use global_live_at_start
to limit propagation, unfortunately I ran into problems with later
compiler passes blowing up if VRP called life_analysis.  I plan to
revisit this issue at some point.

-- John
-------------------------------------------------------------------------
|   Feith Systems  |   Voice: 1-215-646-8000  |  Email: john@feith.com  |
|    John Wehle    |     Fax: 1-215-540-5495  |                         |
-------------------------------------------------------------------------