On Fri, Jul 14, 2023 at 8:35 AM Jeff Law <jeffreya...@gmail.com> wrote: > > > > On 7/13/23 09:05, Manolis Tsamis wrote: > > In this version I have made f-m-o able to also eliminate constant > > moves in addition to the add constant instructions. > > This increases the number of simplified/eliminated instructions and is > > a good addition for RISC style ISAs where these are more common. > > > > This has led to pr52146.c failing in x86, which I haven't been able to > > find a way to fix. > > This involves directly writing to a constant address with -mx32 > > > > The code > > movl $-18874240, %eax > > movl $0, (%eax) > > > > is 'optimized' to > > movl $0, %eax > > movl $0, -18874240(%eax) > > > > Which is actually > > movl $0, -18874240 > > > > which is wrong per the ticket. > > The fix for the ticket involved changes to legitimate_address_p which > > f-m-o does call but it doesn't reject due to the existence of (%eax) > > which in turn is actually zero. > > I believe this is not strictly an f-m-o issue since the pass calls all > > the required functions to test whether the newly synthesized memory > > instruction is valid. > > > > Any ideas on how to solve this issue is appreciated. > I wonder if costing might be useful here. I would expect the 2nd > sequence is the most costly of the three if address costing models are > reasonably accurate. > > Another way would be to look at the length of the memory reference insn. > If it's larger, then it's likely more costly. > > That's what I've got off the top of my head. >
I could test whether the cost function prefers the version that we want, but that would be a workaround I would like to avoid. It may also be the case that this reproduces with a different sequence where the unwanted code is actually more profitable. I was trying to find out whether the original fix can be extended in a way that solves this, because having an address that is reported as legitimate but is actually not could also create issues elsewhere. But I don't yet have a suggestion on how to fix it yet. Thanks, Manolis > Jeff
