This is the mail archive of the
mailing list for the GCC project.
PATCH - cse of sub-expressions of zero_extend/sign_extend expressions
- From: Fariborz Jahanian <fjahanian at apple dot com>
- To: gcc-patches at gcc dot gnu dot org
- Date: Thu, 20 Nov 2003 09:49:51 -0800
- Subject: PATCH - cse of sub-expressions of zero_extend/sign_extend expressions
We found this after implementing mixed 32/64 bit mode on RS6000 in the
FSF3.4 branch. It causes certain cse
optimization not to take place in Vortex program of the SPEC benchmark.
A sample test case is shown below.
In this test case and with -O2 -mpowerpc64 (darwin's 32/64 bit mixed
mode), the if-statement is not eliminated.
void OmNewObject (void** Object)
void* Ptr = 0;
Ptr = (void* )RegionObjects;
*Object = (void*)RegionObjects;
if (Ptr != *Object)
RegionObjects = 4567;
FSF3.4 now generates new patterns with -mpowerpc64 even when 'long
long' is not in use.
A case in point is routine rs6000_emit_move. Since in this mode,
word_mode is DImode, source is promoted to
DImode using zero_extend insn. New patterns is not recognized in cse.
Cause of the problem is the following two insns:
(insn 24 23 26 0 (set (mem:SI (reg/v/f:SI 118 [ Object ]) [0 S4 A32])
(reg:SI 126 [ RegionObjects ])) -1 (nil)
(insn 24 22 25 0 (set:DI (reg:DI 130)
(zero_extend:DI (mem:SI (reg/v/f:SI 118 [ Object ]) [0 S4
A32]))) -1 (nil)
The mem sub-expression of 'zero_extend' insn (2) is common with LHS
of 'set' insn (1). But hashing is done on the
'zero_extend' opcode and thus commonality goes undetected. This patch
does 2nd level of hash lookup when the
primary lookup on the zero_extend insn fails. Patch has been
bootstrapped and dejagnu tested on powerpc-darwin.
Vortex which exposed this problem also passes and expected optimization
2003-11-20 Fariborz Jahanian <email@example.com>
* cse.c (cse_insn): common sub-expression of
zero_extend/sign_extend need be eliminated.
Description: Text document
Fariborz Jahanian <firstname.lastname@example.org>