This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: insn length attribute and code size optimization
On Tue, Feb 9, 2010 at 5:02 PM, Richard Sandiford
<rdsandiford@googlemail.com> wrote:
> Daniel Jacobowitz <dan@codesourcery.com> writes:
>> On Wed, Feb 03, 2010 at 06:23:19AM -0800, Ian Lance Taylor wrote:
>>> fanqifei <fanqifei@gmail.com> writes:
>>>
>>> > According to the internal manual, insn length attribute can be used to
>>> > to calculate the length of emitted code chunks when verifying branch
>>> > distances. Can it be used in code size optimization?
>>>
>>> I suppose it could, but it isn't. ?Instead of asking the backend for
>>> the length of instructions, the compiler asks the backend for the cost
>>> of instructions. ?The backend is free to determine that cost however
>>> it likes. ?When using -Os, using the size of the instruction is a good
>>> measure of cost.
>>
>> It seems to me that there's a hard ordering problem here: we can't
>> determine insn lengths, using the current framework, until very late.
>> We need at least (A) whole instructions, not just RTL expressions; (B)
>> register allocation to select alternatives; (C) branch shortening to
>> determine branch alternatives.
>>
>> I'm curious if anyone thinks there's a generic solution to this (that
>> doesn't involve a complete instruction selection rewrite :-).
>
> Yeah, it's something I've often wanted too, since at the moment you end
> up duplicating a lot of the instruction selection in C code. ?E.g. the
> MIPS port has stuff like:
>
> ? ?[ snip ]
>
> Ugh!
>
> But I could never see a cure that was better than the disease without
> (as you say) a rewrite. ?I think (A) is the main problem: we already
> have code to estimate constraints selection before reload, so we could
> at least guess at (B) and (C). ?(Which is what the costs have to do
> anyway really.)
>
> Richard
GAS knows this information for each insn.
Perhaps binutils should export a library with a facility to encode a
single insn in a buffer? That seems imprudent, making GCC dependent
on binutils.
Maybe the encoding/decoding tables should be broken out into a
separate project? But you still need the chunk of logic (md_assemble,
in the i386 code) to render the instruction to get the insn lengths.
--
Quentin