From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2038 invoked by alias); 2 Oct 2006 19:16:18 -0000 Received: (qmail 1999 invoked by uid 48); 2 Oct 2006 19:16:06 -0000 Date: Mon, 02 Oct 2006 19:16:00 -0000 Message-ID: <20061002191606.1998.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug rtl-optimization/29294] 4.1, 4.2 (possibly 4.0?) not finding postmodify address mode on ARM In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "eplondke at gmail dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-10/txt/msg00165.txt.bz2 List-Id: ------- Comment #4 from eplondke at gmail dot com 2006-10-02 19:16 ------- (In reply to comment #3) > Actually this case should not be using post modify at all except how many bits > does ARM have to use for an offset? I thought 16bits which means you don't need > that at all and GCC should generate it without an increment. Oh and this is a > RTL opt issue. > ARM normal arithmetic operands support an 8-bit integer rotated right by an even number of bits (0-30). If you rotate at all some microarchitectures may cause stalls (Xscale maybe?)... Load and Store word (and unsigned byte) have a +/- 12-bit offset. Load and store other single values has a +/- 8-bit offset. Load and store multiple may have no offset. That's for ARM. For THUMB, you get + 5 bits. Both ARM and THUMB mode have postincrement modes. ARM gets a decent postmodify. For THUMB you use the Load Multiple Increment After instruction with a single regster specified. Looks like CSE1 is the first time that (set (reg) (mem (reg))) gets converted to (set (reg) (mem (plus (reg) (4)))) I have noticed a propensity for postmodify to not be used in several targets comparing GCC 4.X to GCC 3.X. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29294