This is the mail archive of the binutils@sourceware.org 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]
Other format: [Raw text]

Re: [PATCH 4/9] Add ELFv2 .localentry support.


On Wed, Oct 30, 2013 at 12:08:28PM -0700, Richard Henderson wrote:
> Is this really the best definition?  How might one record that one that there
> is no local entry point, i.e. one must always enter with r12 set to the global
> entry address?

You're correct, we don't allow that possibility, but it doesn't seem a
particularly useful option.  Why would you not want a local entry?

> Why have you chosen an encoding that records powers of 2?  Are you really ever
> going to have 32 insns in the global entry point before the local entry point?
> 
> I would have thought that one would pretty much always have exactly two insns
> in the global entry point before the local entry point (addis+addi).  Reserving
> 3 bits would allow 0-7 insns to be skipped, which still seems way more than enough.

The thought behind the encoding was to allow both global and local
entries to be cache line aligned.

It's true that current gcc support just generates addis,addi before
the local entry, but this really doesn't support -mcmodel=large
properly.  We'll need to change that to ld,add and store a 64-bit
offset before the function, or ld,b,dword offset,add.  There are other
interesting possibilities too..  For instance, if you align the toc
correctly then non-pic executables can just use a single lis.

> Compare your scheme with the one used on Alpha, where we have two bits in
> s_other to optimize this.  If STO_ALPHA_NOPV is set, then local_entry ==
> global_entry, equivalent to your st_other == 0 above.  If STO_ALPHA_STD_GPLOAD
> is set, then local_entry == global_entry + 8.  If neither bit is set, then
> there is no local_entry and the global_entry must be used.
> 
> For dealing with hand-written assembly, this requirement that the user actually
> set the .localentry before local entry optimization occurs seems the safest route.

We really have more stringent requirements on the global entry point,
and it's accidental use of the global entry, eg. fall through from one
function into another, that has caused some trouble with hand-written
assembly.

-- 
Alan Modra
Australia Development Lab, IBM


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