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
