From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31854 invoked by alias); 8 Oct 2004 13:48:18 -0000 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 Received: (qmail 31813 invoked from network); 8 Oct 2004 13:48:15 -0000 Received: from unknown (HELO he303war.uk.vianw.net) (195.102.244.166) by sourceware.org with SMTP; 8 Oct 2004 13:48:15 -0000 Received: from [217.204.252.50] (helo=llama.elixent.com) by he303war.uk.vianw.net with asmtp (Exim 4.20) id 1CFv6U-0000rc-1W; Fri, 08 Oct 2004 14:48:14 +0100 Content-Disposition: inline Content-transfer-encoding: quoted-printable MIME-Version: 1.0 Cc: GCC , Nick Ing-Simmons Subject: Re: TMSC320C6x port: return label is being deleted In-Reply-To: <416167CF.8050106@cs.tu-chemnitz.de> from =?UTF-8?B?QWRyaWFuIFN0csOkdGxpbmc=?= on Mon, 04 Oct 2004 17:10:07 +0200 References: <20040916180303.14790.qmail@web86108.mail.ukl.yahoo.com><20041004130045.6901.3@llama.elixent.com><416167CF.8050106@cs.tu-chemnitz.de> Content-type: text/plain; charset="UTF-8" To: adrian.straetling@cs.tu-chemnitz.de Message-Id: <20041008134811.9516.7@llama.elixent.com> Date: Fri, 08 Oct 2004 13:56:00 -0000 From: Nick Ing-Simmons Reply-To: Nick Ing-Simmons X-SW-Source: 2004-10/txt/msg00338.txt.bz2 =3D?UTF-8?B?QWRyaWFuIFN0csOkdGxpbmc=3D?=3D writes: >>I haven't got my code anymore - I left it at TI. >>But I seem to recall that my call define expanded=20 >>into the load-return and the jump. And the jump had a (fake) dependancy=20 >>on the return address register to keep them in right order. >> >Thanks, I'll keep that in mind. For the moment I'll stick to the=20 >solution that's based on the idea: "the compiler doesn't need to know".=20 >The call_expand function inserts the labelno with the appropriate=20 >insn_uid of the call insn into a 'private' hash_table. The output code=20 >later looks into this table to find the labelno and put it out after the=20 >call. > >In the same has table I store information about the cycle this insn was=20 >scheduled. This way I recognize how many nops (if any) need to be=20 >inserted to preserve dependencies. >The drawback of that solution is that I am not able to use the delay=20 >branch scheduler because it destroys those information when regrouping ins= n. > >Do you recall how you did the NOP insertion back then? I am reasonably sure that I used the normal branch scheduler. Almost always the "load return" ended up in the delay slots :-)