------- Comment #9 from matz at gcc dot gnu dot org 2010-03-22 16:01 ------- For sched-deps.c there are two calls to cselib_lookup: 1) in sched_analize_1 (for writing to MEM) 2) in sched_analize_2 (for reading a MEM)
Regarding (2): cselib_lookup is called on a copy of X (made into T) which then is replaced into XEXP(t,0). But for debug-insn that very T isn't used at all further down. So we can disregard the use at (2) (and move the whole manipulation of T into the !DEBUG_INSN_P block). Regarding (1): Here we don't handle debug-insns specially, but sched_analize_1 is called only on PRE/POST_DEC/INC/MODIFY, top-level SET/CLOBBER insns (maybe in a PARALLEL) or CLOBBERS in CALL_INSN_FUNCTION_USAGE. It better should be true that debug-insn don't contain a PRE/POST_DEC/INC/MODIFY side-effect, or a top-level SET/CLOBBER. IOW sched_analyze_1 never should be called on debug-insns. So we can disregard case (1) too. Next: if the cselib_lookup calls (that always have their 'create' argument be true) ever create a new VALUE for a MEM in a debug-insn, that same wouldn't happen without debug-insn, or in different order. I think this would lead to debug-miscompare later down anyway. So, I think any calls into cselib on debug-insns that happen to create new values are actually bugs waiting to be discovered. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42977
