Dave Korn - Why doesn't combine like volatiles? (volatile_ok again, sorry!) (original) (raw)

This is the mail archive of the gcc@gcc.gnu.orgmailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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....


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]