[PATCH] Add missing #include <unistd.h> to libdl.c

[Denys Vlasenko]

On Sunday 25 May 2008 23:06, Paul Brook wrote:
> > > Yeah, sounds logical. I'd do this too, but I don't have sufficient faith
> > > in gcc not being stupid.
> >...
> > > I can easily imagine that on some architecture gcc may have
> > > 32-bit bool. It may be dictated by ABI or gcc may just be stupid again.
> > > I'd prefer to not being constrained by gcc's choice,
> > > but to make this choice independently from gcc.
> >
> > Maybe I am too paranoid? What do you think
> 
> Depends what your criteria are. If you want absolute smallest writable data 
> size then you should probably be using char. If you want smallest overall  
> size (including code)

I want smallest overall size, with slight bias towards small data
(NOMMU benefits from such bias).

> there probably isn't a good single choice.. 

That's why size of smallint is made arch-specific.

> It's not that uncommon for 32-bit loads/stores to be significantly faster than 
> byte accesses.

It's likely to be unmeasurable.

> > > From past experience, gcc *can be* stupid. On i386, it aligns
> > > explicitly defined string arrays to 32 bits.
> 
> There are good performance reasons for this.

Unless I pass -Os. I said "I want smaller size, I don't care about
slight performance loss". If I want alignment in some important case,
I can always use appropriate attribute.

> On many RISC targets this means you can use word accesses.

Word accesses for what? Most operations on strings (like open-coded
byte-by-byte processing) use byte ops anyway, and strlen/strchr/etc
can be optimized to deal with unaligned beginning of a string.

And lastly, I made smallint == char on i386, not on RISC machines.

> Even on x86 it can give measurable speedup due to  
> better cacheline performance.

Additional padding increases, not decreases overall number of cachelines
used, and can even make a particular string to overflow a cacheline
whereas without padding it would not. Example with 33 byte line
starting to span two cachelines after alignment:

[64-byte cacheline][64-byte cacheline][64-byte cacheline]
   unaligned_string

After alignment:

[64-byte cacheline][64-byte cacheline][64-byte cacheline]
         aligned_string
         ^ 32th byte in the cacheline

In other words: you -O2 guys should realize that -Os world view
also have some merits. Next time when Mozilla will OOM crash on you -
recall this.
--
vda