This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: -funsafe-loop-optimizations


Giovanni Bajo wrote:

You are bringing the issue from a techinical point of view into a matter of
personal taste. You probably don't care about them, others might find
unreasonable to silently break that ISO C compliant code. Fine. I was just
asking if, from a technical point of view, that overhead is going to show up in
usual (non micro) benchmarks or not.

I think you miss my point. Your suggested approach has a significant overhead. It slows down some programs by making them larger, and increasing icache pressure. That may be a small effect, but we need to be sure that the value of the optimization is worth while.

There are three approaches here:

1. Do things right in the straightforward way. Actually on some architectures,
the cost for doing things right is not that great if you look at how things
actually play out with multiple execution units. One approach for example is
to do the comparison before the increment, and then on an equality, test for
the special case of an infinite loop.

2. Provide an option to say "don't worry, I never use junk infinite loops in
my code, go ahead and compile code with this assumption". Whether or not to
make this option the default is an orthogonal issue, whether or not to generate
warnings is also an orthogonal issue (e.g. warnings may be useful even if you
follow case 1).

3. Do some hybrid approach generating code for the two cases. This basically
needs to be compared in performance to 1, and it is not clear at all that it
is more desirable than 1. As usual the only way to get decisive information
is to do the experiment, and the results may well be target dependent.

O


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]