From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-71675-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 13966 invoked by alias); 10 Apr 2003 10:13:23 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 13957 invoked from network); 10 Apr 2003 10:13:23 -0000
Received: from unknown (HELO mail.libertysurf.net) (213.36.80.91)
  by sources.redhat.com with SMTP; 10 Apr 2003 10:13:23 -0000
Received: from localhost.localdomain (213.36.79.69) by mail.libertysurf.net (6.5.026)
        id 3E8A4CE6001752C8; Thu, 10 Apr 2003 12:13:12 +0200
Content-Type: text/plain;
  charset="iso-8859-1"
From: Eric Botcazou <ebotcazou@libertysurf.fr>
To: Jan Hubicka <jh@suse.cz>
Subject: Re: Reload bug
Date: Thu, 10 Apr 2003 14:25:00 -0000
User-Agent: KMail/1.4.3
Cc: gcc@gcc.gnu.org
References: <200304081937.16859.ebotcazou@libertysurf.fr> <200304091105.24896.ebotcazou@libertysurf.fr> <20030409112544.GA12755@kam.mff.cuni.cz>
In-Reply-To: <20030409112544.GA12755@kam.mff.cuni.cz>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <200304101201.50800.ebotcazou@libertysurf.fr>
X-SW-Source: 2003-04/txt/msg00418.txt.bz2

> Concerning this testcase, the reload used to manage to get around this
> problem.  It didn't get around intentionally and just because the
> instruction contrain does not accept SSE register so reload is needed
> anyway.

I think you're completely right: the reload pass has no specific 
infrastructure for dealing with invalid subregs. It may "fix" these subregs, 
but only if it happens that the operand needs reloading because of the insn 
constraints.

I now have an example: PR target/10286

We pass

(insn 33 30 35 (set (subreg:SI (reg/v:DI 67) 4)
        (mem/f:SI (plus:SI (reg/f:SI 16 argp)
                (const_int 4 [0x4])) [0 hi+0 S4 A32])) 45 {*movsi_1} 
(insn_list 30 (nil))

to reload, which produces

(insn 33 30 35 (set (reg:SI 29 emm0)
        (mem/f:SI (plus:SI (reg/f:SI 6 ebp)
                (const_int 12 [0xc])) [0 hi+0 S4 A32])) 45 {*movsi_1} 
(insn_list 30 (nil))
    (nil))

that is, the only reload for insn 33 is

Reloads for insn # 33
Reload 0: reload_in (SI) = (mem/f:SI (plus:SI (reg/f:SI 6 ebp)
                                                        (const_int 12 [0xc])) 
[0 hi+0 S4 A32])
	GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1), optional
	reload_in_reg: (mem/f:SI (plus:SI (reg/f:SI 6 ebp)
                                                        (const_int 12 [0xc])) 
[0 hi+0 S4 A32])


Incidentally, PR target/10286 is a regression from GCC 3.2 present in
GCC 3.2.1 and later. The culprit is this patch:

Sat Oct 19 15:49:14 CEST 2002  Jan Hubicka  <jh@suse.cz>

	* mmintrin.h (__m64): typedef it to v2si.
	(_mm_cvtsi32_si64, _mm_cvtsi32_si64_mm_sll_pi16,
	_mm_sll_pi32, _mm_sll_pi64, _mm_slli_pi64, _mm_sra_pi16,
	_mm_sra_pi32, _mm_srl_pi16, _mm_srl_pi32, _mm_srl_pi64,
	_mm_srli_pi64, _mm_and_si64, _mm_andnot_si64,
	_mm_or_si64, _mm_xor_si64): Add neccesary casts.
	* xmmintrin.h (_mm_setzero_si64): Likewise.

See http://gcc.gnu.org/ml/gcc-patches/2002-10/msg01091.html

Before the patch, __m64 was defined as 'unsigned long long' so (%eax, %edx) 
was used instead of %rmm0 and we didn't produce invalid subregs. I think 
this patch has opened a can of worms and the MMX intrinsics are seriously 
broken on the 3.2 branch now.

-- 
Eric Botcazou