Talk:Peephole optimization

message: I know the article is lacking in quality and clarity, but it's better than nothing. Wouter Lievens 12:38, 4 November 2005 (UTC)
replies: text: Actually this is excellent.  --Jorend 16:35, 14 March 2007 (UTC)

text: 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)
thread_title: untitled

message: 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)
replies: text: 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)
thread_title:  Removing redundant code example is wrong 

message: 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)
thread_title:  Replacement rules 

message: 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)
thread_title:  Needs references for introduction 

message: 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)
thread_title:  Missing important detail 

message: 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)
thread_title:  Sentance ends in the middle