On 7/16/24 4:29 AM, Georg-Johann Lay wrote:
Am 15.07.24 um 19:53 schrieb Richard Sandiford:
Georg-Johann Lay <a...@gjlay.de> writes:
In a test case I see insn combine trying to match such
expressions, which do not make any sense to me, like:
Trying 2 -> 7:
2: r45:HI=r48:HI
REG_DEAD r48:HI
7: {r47:HI=r45:HI|r46:PSI#0;clobber scratch;}
REG_DEAD r46:PSI
REG_DEAD r45:HI
Failed to match this instruction:
(parallel [
(set (reg:HI 47 [ _4 ])
(ior:HI (clobber:HI (const_int 0 [0]))
(reg:HI 48)))
(clobber (scratch:QI))
])
and many other occasions like that.
Is this just insn combine doing its business?
Or should this be some sensible RTL instead?
Seen on target avr with v14 and trunk,
attached test case and dump compiled with
(clobber:M (const_int 0)) is combine's way of representing
"something went wrong here". And yeah, recog acts as an error
detection mechanism in these cases. In other words, the idea
is that recog should eventually fail on nonsense rtl like that,
so earlier code doesn't need to check explicitly.
Richard
Hi Richard,
I never saw this before; and the point is that in some functions,
combine is almost exclusively producing these rtxes with clobber
const_int, but almost no meaningful combinations. Like in:
Perhaps, but the convention of using a (clobber (const_int 0)) for cases
where combine gets "lost" has been around for decades.
Jeff
