mirror of
git://gcc.gnu.org/git/gcc.git
synced 2025-03-16 09:30:38 +08:00
gcc.texi (Non-bugs): ``Empty'' loops will be optimized away in the future...
* gcc.texi (Non-bugs): ``Empty'' loops will be optimized away in the future; indeed that already happens in some cases. From-SVN: r24442
This commit is contained in:
parent
30dfe54ae2
commit
c2a2650529
@ -1,3 +1,8 @@
|
||||
Mon Dec 28 19:26:32 1998 Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
|
||||
|
||||
* gcc.texi (Non-bugs): ``Empty'' loops will be optimized away in
|
||||
the future; indeed that already happens in some cases.
|
||||
|
||||
Tue Dec 29 11:58:53 1998 Richard Henderson <rth@cygnus.com>
|
||||
|
||||
* sparc.c (input_operand): Recognize (const (constant_p_rtx)).
|
||||
|
16
gcc/gcc.texi
16
gcc/gcc.texi
@ -2005,12 +2005,18 @@ test explicitly for C++ as well.
|
||||
@item
|
||||
Deleting ``empty'' loops.
|
||||
|
||||
GNU CC does not delete ``empty'' loops because the most likely reason
|
||||
you would put one in a program is to have a delay. Deleting them will
|
||||
not make real programs run any faster, so it would be pointless.
|
||||
Historically, GNU CC has not deleted ``empty'' loops under the
|
||||
assumption that the most likely reason you would put one in a program is
|
||||
to have a delay, so deleting them will not make real programs run any
|
||||
faster.
|
||||
|
||||
It would be different if optimization of a nonempty loop could produce
|
||||
an empty one. But this generally can't happen.
|
||||
However, the rationale here is that optimization of a nonempty loop
|
||||
cannot produce an empty one, which holds for C but is not always the
|
||||
case for C++.
|
||||
|
||||
Moreover, with @samp{-funroll-loops} small ``empty'' loops are already
|
||||
removed, so the current behavior is both sub-optimal and inconsistent
|
||||
and will change in the future.
|
||||
|
||||
@item
|
||||
Making side effects happen in the same order as in some other compiler.
|
||||
|
Loading…
x
Reference in New Issue
Block a user