This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Does -flto give gcc access to data addresses?


On Thu, Sep 11, 2014 at 10:17 PM, Jeff Prothero <jprother@altera.com> wrote:
>
> Hi, I'm having trouble based on available docs like
>     https://gcc.gnu.org/onlinedocs/gccint/LTO.html
> in understanding just what the gcc LTO framework is
> intended to be architecturally capable of.
>
> As a concrete motivating example, I have a 32K embedded
> program about 5% of which consists of sequences like
>
>         movhi   r2,0
>         addi    r2,r2,26444
>         stw     r15,0(r2)
>
> This is on a 32-bit RISC architecture (Nios2) with 16-bit
> immediate values in instructions where in general a
> sequence like
>
>         movhi   r2,high_half_of_address
>         addi    r2,r2,low_half_of_address
>
> is required to assemble an arbitrary 32-bit address in
> registers for use.
>
> However, if the high half of the address happens to be
> zero, (which is universally true in this program because
> code+data fit in 64KB -- forced by hardware constraints)
> we can collapse
>
>         movhi   r2,0
>         addi    r2,r2,26444
>         stw     r15,0(r2)
> to just
>         stw     r15,26444(r0)
>
> saving two instructions. (On this architecture
> R0 is hardwired to zero.)
>
> This seems like a natural peephole optimization at
> linktime -- *if* data addresses are resolved in some
> (preliminary?) fashion during linktime code generation.
>
> Is this a plausible optimization to implement in gcc
> + binutils with the current -flto support architecture?
>
> If so, what doc/mechanism/approach/sourcefile should
> I be studying in order to implement this?
>
> If not, is there some other productive way to tickle
> gcc + binutils here?

I don't think LTO will help you here.  Usually targets add
a flag like -msmall and simply generate the shorter sequence,
leaving the linker to complain if it can't resolve the address
with the smaller relocation type.

Which also means the linker could suggest to use -msmall
if _all_ larger relocations would have fit into the smaller
variant.

Richard.

> Thanks in advance,
>  -Jeff
>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]