This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


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

Re: Performance problem with gas


Kai Schuetz <ks@axys.de> writes:

> I've got the following problem: we've regulatry compiling some large
> functions containing a big, generated switch construct. When it comes to
> assembling it it takes a lot of time (5, even 10 minutes). I did a
> profiling or gas an saw that the function "is_dnrange" eats up 99.55% of
> all time.
> 
> It's called from relax_frag where I read the comment "There should be a
> faster way to do this.".
> 
> How difficult would it be to speed this up ?

You neglected to mention what target you are using, and what type of
debugging information you are using.  It makes a difference because
different targets and different debugging types will have different
frag usage.

Frags are always created in order.  So one fast check you could add is
to check fr_line; if f1->fr_line becomes larger than f2->fr_line, then
there is no point to looking any further.

Another quick check you could do would be to compare the symbol
segment with the segment being relaxed.  This would require passing
the segment into relax_frag; note that it is called by a couple of
config/*.c files as well.

> I don't know to much about gas but is seem that the frag data structure
> is very basic for the whole assembler, so changing it might have the
> consequence of changing a whole lot of code ?

Changing it significantly would affect a lot of code.  But you
shouldn't need to change it significantly to speed up this function.

> Is the slowdown I'm experiencing just a rare case or would enhancing
> this speed up the whole assembler ?

Impossible to say based on the information you have provided.

Ian


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