Modulo optimizations

"Graham Marshall" <gmarshal@globalnet.co.uk>
4 Oct 1999 12:10:06 -0400

          From comp.compilers

Related articles
Modulo optimizations gmarshal@globalnet.co.uk (Graham Marshall) (1999-10-04)
Re: Modulo optimizations jgk@jgk.org (Joe Keane) (1999-10-11)
Re: Modulo optimizations torbenm@diku.dk (1999-10-13)
Re: Modulo optimizations chase@world.std.com (David Chase) (1999-10-13)
Re: Modulo optimizations ger@informatik.uni-bremen.de (George Russell) (1999-10-14)
Re: Modulo optimizations harley@corton.inria.fr (Robert Harley) (1999-10-14)
Re:Modulo optimizations Wilco.Dijkstra@arm.com (Wilco Dijkstra) (1999-10-19)
[2 later articles]
| List of all articles for this month |

From: "Graham Marshall" <gmarshal@globalnet.co.uk>
Newsgroups: comp.compilers
Date: 4 Oct 1999 12:10:06 -0400
Organization: GXSN
Keywords: code, practice

Hi Guys,


I'd like to have some input on what a compiler optimizer is likely to do in
the following scenario.


I have a computation in my code which does a modulo divide:


                                x = y % z;


If I understand correctly, if z is a power of 2, the optimizer can
emit faster code (perhaps using shifts etc.) to take advantage of
this. However, what happens if the value of z is not known at
compile-time, but only at run-time. Will the optimizer:


        a) Only emit the general modulo case code, since the value of z is not
known at compile-time, or
        b) Emit code for the general case AND the faster case and evaluate z at
run-time and select the appropriate
                  routine to execute?


My gut feeling (as a naive user) is that a modern compiler would do
b), and that this may be one of the reasons why faster executables can
often be greater in size when full optimization is switched on.


I'd be grateful for any input on this - thanks in advance,
Graham
[These days arithmetic is fast, conditional jumps are slow, so it's hard
to imagine that anything other than a single divide instruction would be
faster for unknown z. Executables get big because of loop unrolling and
in-line expansion of routines. -John]



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.