On 2023/01/23 0:45, Max Filippov wrote: > On Fri, Jan 20, 2023 at 8:39 PM Takayuki 'January June' Suwa > <jjsuwa_sys3...@yahoo.co.jp> wrote: >> On 2023/01/21 0:14, Max Filippov wrote: >>> After having this many attempts and getting to the issues that are >>> really hard to detect I wonder if the target backend is the right place >>> for this optimization? >>> >> I guess they are not hard to detect > > I mean, on the testing side. check-gcc testsuite passed without new > regressions with this change, linux kernel smoke test passed, I was > almost convinced that it's ok to commit. > >> but just issues I didn't anticipate (and I just need a little more work). > > Looking at other peephole2 patterns I see that their code transformations > are much more compact and they don't need to track additional properties > of unrelated instructions. > >> And where else should it be done? What about implementing a >> target-specific pass just for one-point optimization? > > I don't even understand what's target-specific in this optimization? > It looks very generic to me. >
Ah, I seem to have misunderstood what you meant, sorry. Now, what this patch is trying to do depends on whether register moves can be converted to stack pointer indirect loads/stores with offsets, and whether there is any benefit in doing so, but they are not target dependent. Is it? If we want the target-independent part to do something like this, we will need a mechanism (macro, hook, etc.) to write appropriate information in the machine description and pass it on. For example, offset ranges for register indirect loads and stores, or whether the ABI requires that callee-saved registers always be associated with stack slots, or even the need for stack frame construction... I totally agree that the peephole2 pattern is not the best implementation location.
