From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3568 invoked by alias); 22 May 2007 17:36:37 -0000 Received: (qmail 3550 invoked by uid 22791); 22 May 2007 17:36:34 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 22 May 2007 17:36:29 +0000 Received: from zps37.corp.google.com (zps37.corp.google.com [172.25.146.37]) by smtp-out.google.com with ESMTP id l4MHaJ8k026526; Tue, 22 May 2007 10:36:20 -0700 Received: from localhost.localdomain.google.com (dhcp-172-18-119-189.corp.google.com [172.18.119.189]) (authenticated bits=0) by zps37.corp.google.com with ESMTP id l4MHZqZN003593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 May 2007 10:35:52 -0700 To: Roman Zippel Cc: Eric Botcazou , gcc-patches@gcc.gnu.org, Rask Ingemann Lambertsen , Uros Bizjak , Paolo Bonzini , Chris Lattner Subject: Re: [PATCH, x86_64]: Provide longlong.h definitions for 128bit operations References: <464B6834.1050600@gmail.com> <20070517213750.GZ5690@sygehus.dk> <200705180912.20137.ebotcazou@libertysurf.fr> From: Ian Lance Taylor Date: Tue, 22 May 2007 17:36:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-05/txt/msg01468.txt.bz2 Roman Zippel writes: > I'm playing around with it a little on m68k and there is sometimes a bit > of a conflict. E.g. I would split somthing like adddi3/subdi3 already > before combine, because the addx/subx instruction is much more limited in > its addressing mode (only accepts register), so combine can generate the > right instructions. That's right. That's why I recommend a define_insn_and_split. The insn will be complete for most of the RTL optimization passes, including combine. It will then be split before the second lower subreg pass and before register allocation. Of course, that won't help your case, because you want to split before combine for other reasons. > I think the reload problem may not be that bad, while a move instruction > sets the cc register, it often just sets it in the same way as the > previous instructions, especially the Z and M flag, which is enough for > the common test against zero. For these tests the move wouldn't really > clobber the flags, but just recreate them. It's unfortunately not that simple. In some cases reload will need to load some part of an address. When it does that the flags will no longer have any relation to what they are supposed to have. > A bit more difficult is a sub/cmp combination, here move would really > clobber flags, but luckily on m68k the sub instruction is quite flexible > and e.g. also accepts memory arguments as destination, so it would be > possible to convert a output reload into one or two input reloads. > So what basically would be needed is a port specific check in reload as to > whether an output reload is acceptable and possibly reject the > alternative and try it with another one. > That's currently the idea I would favour at least for m68k, does that > sound reasonable (or at least understandable :) ). That sounds unreasonable. reload is already very complicated, too complicated, and there isn't going to be any way to drop in something like that without making it significantly more complicated. Ian