public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* [LM-32] Code generation for address loading
@ 2014-02-18 14:05 FX MOREL
  2014-02-25  0:09 ` Anthony Green
  0 siblings, 1 reply; 3+ messages in thread
From: FX MOREL @ 2014-02-18 14:05 UTC (permalink / raw)
  To: gcc

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.

In the C code, regrouping variables in structure will generate code
where memory is accessed through an offset of the base address of the
structure which is only loaded once per function, hence a gain in code
size.
But the extent of this technique is still limited by C code
readability constraints and there is still at least one penalty in
each function to load the first address.

I was imagining something with a fixed register (say r23, declared as
-ffixed in compilation flags) that would be loaded with the addresses'
hi-part at reset (in the same ways that r0 is set to 0) and then each
address loading phase would only consist in one instruction :

  ori r1, r23, 0xLLLL

I have tried to play around with machine description file of the lm32
architecture to achieve my goal but I need some kind of constraints or
condition to check where is my symbol before using this shortened
version of address loading (Even if nearly all of the symbols are
located within the same 64kB, some are still located in other memory
regions and I don't want to touch them !)

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.

Thank you.

F-X Morel

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [LM-32] Code generation for address loading
  2014-02-18 14:05 [LM-32] Code generation for address loading FX MOREL
@ 2014-02-25  0:09 ` Anthony Green
  2014-02-26 11:53   ` FX MOREL
  0 siblings, 1 reply; 3+ messages in thread
From: Anthony Green @ 2014-02-25  0:09 UTC (permalink / raw)
  To: FX MOREL; +Cc: gcc

FX MOREL <fxmorel.gcc@gmail.com> 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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [LM-32] Code generation for address loading
  2014-02-25  0:09 ` Anthony Green
@ 2014-02-26 11:53   ` FX MOREL
  0 siblings, 0 replies; 3+ messages in thread
From: FX MOREL @ 2014-02-26 11:53 UTC (permalink / raw)
  To: Anthony Green; +Cc: gcc

On Tue, Feb 25, 2014 at 1:08 AM, Anthony Green <green@moxielogic.com> wrote:

>
> Have you considered doing this through custom GNU linker relaxation
> work?  I would try this before hacking away at the compiler.
>
> AG
>
>

This a very good idea indeed, I wasn't aware of this feature.
I will give it a try based on other relaxations done for other platforms...
Thank you for your input and I will let you know if I have any success

FX

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2014-02-26 11:53 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-18 14:05 [LM-32] Code generation for address loading FX MOREL
2014-02-25  0:09 ` Anthony Green
2014-02-26 11:53   ` FX MOREL

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).