Re: [PATCH v3] Implement new RTL optimizations pass: fold-mem-offsets.

[Jeff Law <jeffreyalaw@gmail.com>]

On 7/20/23 00:18, Vineet Gupta wrote:
> 
> 
> On 7/18/23 21:31, Jeff Law via Gcc-patches wrote:
>>>
>>> In a run with -fno-fold-mem-offsets, the same insn 93 is successfully 
>>> grok'ed by cprop_hardreg,
>>>
>>> | (insn 93 337 522 11 (set (mem/c:DF (plus:DI (reg/f:DI 2 sp)
>>> |                (const_int 8 [0x8])) [4 %sfp+-8 S8 A64])
>>> |        (const_double:DF 0.0 [0x0.0p+0])) "sff.i":23:11 190 
>>> {*movdf_hardfloat_rv64}
>>> ^^^^^^^^^^^^^^^
>>> |     (expr_list:REG_EQUAL (const_double:DF 0.0 [0x0.0p+0])
>>> |        (nil)))
>>>
>>> P.S. I wonder if it is a good idea in general to call recog() post 
>>> reload since the insn could be changed sufficiently to no longer 
>>> match the md patterns. Of course I don't know the answer.
>> If this ever causes a problem, it's a backend bug.  It's that simple.
>>
>> Conceptually it should always be safe to set INSN_CODE to -1 for any 
>> insn.
> 
> Sure the -1 should be handled, but are you implying that f-mo- will 
> always generate a valid combination and recog() failing is simply a bug 
> in backend and/or f-m-o. If not, the -1 setting can potentially trigger 
> an ICE in future.
A recog failure after setting INSN_CODE to -1 would always be an 
indicator of a target bug at the point where f-m-o runs.

In that would be generally true as well.  There are some very obscure 
exceptions and those exceptions are for narrow periods of time.



> 
>>
>> Odds are for this specific case in the RV backend, we just need a 
>> constraint to store 0.0 into a memory location.  That can actually be 
>> implemented as a store from x0 since 0.0 has the bit pattern 0x0. This 
>> is probably a good thing to expose anyway as an optimization and can 
>> move forward independently of the f-m-o patch.
> 
> I call dibs on this :-) Seems like an interesting little side project.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748
It's yours  :-)

jeff