Talk:Peephole optimization

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Software (assessed as Low-importance).

untitled[edit]

I know the article is lacking in quality and clarity, but it's better than nothing. Wouter Lievens 12:38, 4 November 2005 (UTC)[reply]

Actually this is excellent. --Jorend 16:35, 14 March 2007 (UTC)[reply]

Your optimisation example is incorrect, as the value of a is not written back from the stack in the second example. If a where to be referenced later in the program, it would not be the correct value. However, if a was never accessed again, that would be a valid optimisation, but you would need to state that the compiler knew this was the case. Mattmilford 19:24, 16 October 2007 (UTC)[reply]

Is it possible for a compiler todo optimized loading of constants like this:

- i have the value 10000 in regX which is used no longer 
- i need the constant 20000 for the next operation
- instead of loading 20000 i do regX+= regX

This would save space in the L1 cache. I guess this *2 example is not very practical but if you use all instructions of a given architecture (like LEA on X86 for fast multiply) you could save some constant loading, and even more on 64 bit architectures where opcodesize would be opcode + 8 byte data. The drawback like with most optimizations would be much longer compiling times. —Preceding unsigned comment added by 94.222.5.89 (talk) 20:47, 25 January 2009 (UTC)[reply]

Removing redundant code example is wrong[edit]

When removing redundant POP/PUSH pairs where is it being considered that the call to the second function needs those registers with the right values? The first function call might have modified any of those registers and therefore POPs are needed to restore pre-call values to CPU registers. Then a series of PUSHes are needed to store those registers again to be able to restore values after the second call has finished. TWiStErRob (talk) 07:45, 3 June 2010 (UTC)[reply]

There is an assumption that the second function does not need the values that are in the registers. That is why they have to be copied into the stack before that function is called; it is getting the values from there. Peephole optimization is predicated on certain assumptions about the code, such as calling convention. Peephole optimization does not necessarily have the property that it will preserve the correctness of absolutely any hand-written machine language program. It only has to work with the output of the compiler into which it is integrated.KazKylheku (talk) 16:32, 19 January 2021 (UTC)[reply]

Replacement rules[edit]

The characterization of peephole optimization is far too broad. Constant folding, strength reduction, and dead code elimination are optimatizations in their own right. Furthermore, those optimizations often require information that is not available in just a peephole window.

Peephole optimization looks at a short sequence of instructions and replaces them with a better sequence.

I'd trim the list of "replacement rules". Glrx (talk) 19:15, 28 December 2010 (UTC)[reply]

Needs references for introduction[edit]

I recently edited this page to improve the style and grammar of the introduction, however I was unable to add references to support the material as the original ACM paper on peephole optimization is behind a paywall. If anyone has access to this article and can verify and cite the content in the introduction, it would be much appreciated. Iafisher (talk) 14:58, 7 June 2019 (UTC)[reply]

Missing important detail[edit]

Peephole optimization requires the program to be divided into basic blocks, which are individually peepholed. For instance if we have

          MOV R0, R1
   LABEL: MOV R1, R0
          ...
          JMP LABEL

we cannot remove the MOV R1, R0 at the LABEL because that's the start of a basic block. We must consider the code path whereby control arrives there via the JMP. In that case, R0 and R1 may have different values, and so updating R1 with R0 is meaningful and necessary. That is to say, we must consider that possibility, but peephole optimization will specifically not include that reasoning. It will treat each code segment starting at an instruction which is a branch target to be a separate block, and so, effectively, there is no code before the MOV R1, R0 as far as the peephole is concerned. All peephole reductions whose patterns would span across a branch target are possibly wrong and so are avoided. KazKylheku (talk) 16:40, 19 January 2021 (UTC)[reply]

Sentance ends in the middle[edit]

Please complete the sentence "

instead of multiplying a floating point register by 8, a peephole optimization might add 3 to the floating point register's exponent; and

"ויקיטכני (talk) 16:29, 2 May 2024 (UTC)[reply]