This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Value Range Propagation Patch (Version 3)
- To: John Wehle <john at feith dot com>
- Subject: Re: Value Range Propagation Patch (Version 3)
- From: Toon Moene <toon at moene dot indiv dot nluug dot nl>
- Date: Tue, 11 Jul 2000 12:51:39 +0200
- CC: gcc-patches at gcc dot gnu dot org
- Organization: Moene Computational Physics, Maartensdijk, The Netherlands
- References: <200007110019.UAA03485@jwlab.FEITH.COM>
John Wehle wrote:
> VRP may be of some help in that it'll remove any addition
> checks which appear later in the loop (assuming that
> the frontend actually creates redundant bounds checks).
Yes, it does - it's far to difficult to keep track in the frontend
whether a certain index already has been checked.
> Keeping in mind that I don't know fortran, or how the
> current frontend works consider:
>
> PARAMETER (N=10)
> DIMENSION A(N)
> DO I = 1, N
> A(I) = I
> A(I) = A(I) + 3
> ENDDO
> PRINT*,A
> END
>
> VRP is unable to remove the first check since I is a BIV
> and not based on the loop counter. However, the first
> check does give VRP information about I which it'll use
> to eliminate later bounds checks.
Unfortunately, that doesn't work (yet ?); I've got the feeling VRP gets
confused over the zero-extend using indices on the Alpha (from the -dV
output):
BB 2
reg 70
min <integer_cst 0x1204c1d58 0> max <integer_cst
0x1204c1e18 9>
reg 78
min <integer_cst 0x1204c1ef8 10> max <integer_cst
0x1204c1fb8 4294967295>
reg 79
min <integer_cst 0x1204c2098 0> max <integer_cst
0x1204c2158 1>
reg 136
min <integer_cst 0x1204c2238 9> max <integer_cst
0x1204c22f8 9>
(note 230 27 33 [bb 1] NOTE_INSN_BASIC_BLOCK -1347440721)
(insn 33 230 35 (set (reg:DI 77)
(plus:DI (reg/v:DI 69)
(const_int -1 [0xffffffffffffffff]))) 4 {*lda} (nil)
(nil))
(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)
(expr_list:REG_NONNEG (reg:DI 78)
(nil)))
It would certainly be very useful.
> BTW, why does the current frontend generate both I and a
> separate loop counter?
Because it's easier that way to stick to the wording of the Standard,
which leads to more clarity in the frontend.
--
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://g95.sourceforge.net/ (under construction)