This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Why doesn't combine like volatiles? (volatile_ok again, sorry!)
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: <gcc at gcc dot gnu dot org>
- Date: Mon, 21 Nov 2005 18:12:43 -0000
- Subject: Why doesn't combine like volatiles? (volatile_ok again, sorry!)
Morning gcc-hackers!
I was wondering why combine could piece together two insns like these:
----------------------------<snip!>----------------------------
(insn 11 5 12 0 0x1002f330 (set (reg:QI 74)
(mem:QI (reg/v/f:SI 70) [0 S1 A8])) 25 {movqi} (insn_list 3 (nil))
(expr_list:REG_DEAD (reg/v/f:SI 70)
(nil)))
(insn 12 11 14 0 0x1002f330 (set (reg/v:SI 72)
(zero_extend:SI (reg:QI 74))) 17 {zero_extendqisi2} (insn_list 11
(nil))
(expr_list:REG_DEAD (reg:QI 74)
(nil)))
----------------------------<snip!>----------------------------
into one like this:
----------------------------<snip!>----------------------------
(note 11 5 12 0 NOTE_INSN_DELETED)
(insn 12 11 14 0 0x1002f330 (set (reg/v:SI 72)
(zero_extend:SI (mem:QI (reg/v/f:SI 70) [0 S1 A8]))) 17
{zero_extendqisi2} (insn_list 3 (nil))
(expr_list:REG_DEAD (reg/v/f:SI 70)
(nil)))
----------------------------<snip!>----------------------------
but it fails if the MEM references are volatile:
----------------------------<snip!>----------------------------
(insn 11 5 12 0 0x1002fc60 (set (reg:QI 74)
(mem/v:QI (reg/v/f:SI 70) [0 S1 A8])) 25 {movqi} (insn_list 3 (nil))
(expr_list:REG_DEAD (reg/v/f:SI 70)
(nil)))
(insn 12 11 14 0 0x1002fc60 (set (reg/v:SI 72)
(zero_extend:SI (reg:QI 74))) 17 {zero_extendqisi2} (insn_list 11
(nil))
(expr_list:REG_DEAD (reg:QI 74)
(nil)))
----------------------------<snip!>----------------------------
Looking at it, this seems to be quite deliberate: combine_instructions()
calls init_recog_no_volatile() before it runs the combine pass and
init_recog() afterward. I haven't delved into the morass of machine-generated
loveliness that is insn-recog.c, but by modifying recog_for_combine() to try
calling recog() twice, once with volatiles disabled, and once with them
enabled, I've been able to determine that that's definitely the cause that
prevents the volatile loads from being combined with the zero_extend
operations.
All this is despite the fact that I have "#define LOAD_EXTEND_OP(MODE)
ZERO_EXTEND" in my target header file.
I see from the archives that this has come up before. I found loads of
mails from Mike Stump suggesting to google his name and "volatile_ok" to find
a patch, but I couldn't find it, and I couldn't get a clear impression of what
the real issue is here.
What's a decent solution here? Should I come up with a new version of
general_operand, call it general_or_volatile_operand, that would accept mem/v
references, and use it for the movXX patterns in my md? Or, given that this
is likely to be the most common case and perhaps the only one I'm going to
care about, should I just define a pattern that matches the (set:SI
(zero_extend:SI (mem:QI))) insn directly? Or how about the dodgy hacks that
temporarily reenable volatile_ok and then clear it again after calling the
recognizer?
cheers,
DaveK
--
Can't think of a witty .sigline today....