From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26465 invoked by alias); 21 Nov 2005 18:12:49 -0000 Received: (qmail 26456 invoked by uid 22791); 21 Nov 2005 18:12:49 -0000 X-Spam-Check-By: sourceware.org Received: from host217-40-213-68.in-addr.btopenworld.com (HELO SERRANO.CAM.ARTIMI.COM) (217.40.213.68) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 21 Nov 2005 18:12:47 +0000 Received: from espanola ([192.168.1.110]) by SERRANO.CAM.ARTIMI.COM with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Nov 2005 18:12:44 +0000 From: "Dave Korn" To: Subject: Why doesn't combine like volatiles? (volatile_ok again, sorry!) Date: Mon, 21 Nov 2005 18:12:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2005-11/txt/msg00990.txt.bz2 Morning gcc-hackers! I was wondering why combine could piece together two insns like these: -------------------------------------------------------- (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))) -------------------------------------------------------- into one like this: -------------------------------------------------------- (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))) -------------------------------------------------------- but it fails if the MEM references are volatile: -------------------------------------------------------- (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))) -------------------------------------------------------- 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....