From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27508 invoked by alias); 25 Feb 2014 00:09:03 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 27495 invoked by uid 89); 25 Feb 2014 00:09:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-HELO: mail-qa0-f48.google.com Received: from mail-qa0-f48.google.com (HELO mail-qa0-f48.google.com) (209.85.216.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 25 Feb 2014 00:09:00 +0000 Received: by mail-qa0-f48.google.com with SMTP id o15so191283qap.35 for ; Mon, 24 Feb 2014 16:08:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=wJgN6ULOHNvM8XNd6kVoXw4+z8zJeil856/zl/n/doA=; b=Dkj486vJ9fYSH5mn3kHynZzljpIngT2tTJ1MwZWLaXy+RzfarH7eIRZNDEt0Fod1g9 nakY2bXkMAV2NxNs8BW+vFlA0RfQ5dzH4FUkJllVBiIbfMKzEB+MbrPLgwLL+XDL/rbQ kYYRNZ7D/hK37qXaXPWbqN+ouT6TxZ0Uhk+IrB+DXtrxLaXc+Pn+oTeM2YYVHNfJrlkL 4mNs7QYZLnbuSYcjMizoJg0rEyK9CwbI3GSrNk4qM8pY8xo9kOkNtGvWZQtu1BssGBWe T3m89SXN0jwuIw3xyCBwelMh3tohkkaY0XKFdifonELcHCb1FICtSxmFenp6UwzurWbz dm6w== X-Gm-Message-State: ALoCoQn85+gYfvW/M5hZjW1FPKRgY3AZwYTX3Te7a8H1SOYHuSNZVE7weYiUU+ZATIwURGs3zPVj X-Received: by 10.140.26.240 with SMTP id 103mr32385233qgv.92.1393286938674; Mon, 24 Feb 2014 16:08:58 -0800 (PST) Received: from localhost (dsl-173-206-21-164.tor.primus.ca. [173.206.21.164]) by mx.google.com with ESMTPSA id p67sm27729316qgd.8.2014.02.24.16.08.56 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Feb 2014 16:08:57 -0800 (PST) From: Anthony Green To: FX MOREL Cc: gcc@gcc.gnu.org Subject: Re: [LM-32] Code generation for address loading References: Date: Tue, 25 Feb 2014 00:09:00 -0000 In-Reply-To: (FX MOREL's message of "Tue, 18 Feb 2014 15:04:32 +0100") Message-ID: <87ios4xddt.fsf@moxielogic.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2014-02/txt/msg00473.txt.bz2 FX MOREL writes: > Hi everyone, > > I am developing on a custom design using the LatticeMico32 > architecture and I use gcc 4.5.1 to compile C code for this arch. > > In this architecture, the loading of an address 0xHHHHLLLL always > takes two assembly instructions to fetch the address because > immediates are on 16 bits : > mvhi r1, 0xHHHH > ori r1, r1, 0xLLLL > ... > lw r2, r1 > > In my situation, nearly all the symbols are located in the same 64kB > region and their address share the same hi-part, so I am trying to > minimize the overload of always using two instructions when only one > is needed. > [additional details deleted] > Because the symbol mapping phase is done during linking, I have little > chance to know the future symbol address at code generation but is > there some way I could make this work ? > If I affect the symbol to a dedicated section (with the __attribute__ > ((section())) directive ), is there a way to know its section during > code generation ? > > I understand that I am asking for a very 'dangerous' advice but again, > this will only be a custom optimization for a custom design. Have you considered doing this through custom GNU linker relaxation work? I would try this before hacking away at the compiler. AG > > Thank you. > > F-X Morel