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: Question about insn lengths


On Wed, 2004-11-03 at 02:57, Jeffrey A Law wrote:
> On Tue, 2004-11-02 at 19:06 -0500, DJ Delorie wrote:
> 
> > Personally, I've grown towards letting gas deal with anything that
> > requires knowledge of the actual number bytes emitted, since gas
> > happens to have the exactly correct number anyway, while gcc must try
> > to guess accurately.  Unless there's a compelling reason for gcc to
> > know opcode lengths for other reasons.
> Which is precisely how I think it ought to work as well, except for
> targets which do linker relaxation.
> 
> I once embarked on a project to get 100% accurate insn lengths from
> one of my ports.  After a fair amount of hacking I realized it was
> going to be damn near impossible -- peepholes, reorg and the like
> really get in the way of 100% accurate lengths.
> 
> The exercise was still useful though -- the lengths for the port in
> question (PA) got a lot more accurate, leading to fewer long jumps
> particularly for conditionals.
> 
> Ever since that experience I've fallen into the "if you need 100%
> exact lengths, do the work in the assembler or linker".

Unfortunately that means that GCC can't always generate optimal code. 
The strategy for far jumps on Thumb, for example, means clobbering the
link register (it needs a call instruction).  Not tracking lengths
accurately means you have to mark the register dead at every jump (in
fact the compiler just avoids use of the register entirely at this
time).

It also affects things like constant pool placement, particularly on
Thumb where there is very limited offset addressing from the PC.  The
more inaccurate the instruction size estimates become the more pools
that are needed and the less well placed they become (and with more
duplication of entries).  It's probably a bad idea to do constant pool
placement in the assembler, since it has no concept of loop depth in a
stream of instructions; in cases where the stream has to be forcibly
broken to insert the pool, it's better to try and do it outside of a
deeply nested loop.

It's usually a sufficient condition for correct code to never
underestimate the amount of code needed, but we could do a better job if
we knew exactly how much code we had.

R.


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