2015-05-29 03:09:30 +08:00
|
|
|
//===- Symbols.h ----------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// The LLVM Linker
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#ifndef LLD_COFF_SYMBOLS_H
|
|
|
|
#define LLD_COFF_SYMBOLS_H
|
|
|
|
|
|
|
|
#include "Chunks.h"
|
|
|
|
#include "Config.h"
|
|
|
|
#include "lld/Core/LLVM.h"
|
|
|
|
#include "llvm/ADT/ArrayRef.h"
|
|
|
|
#include "llvm/Object/Archive.h"
|
|
|
|
#include "llvm/Object/COFF.h"
|
2015-07-06 05:54:42 +08:00
|
|
|
#include <atomic>
|
2015-05-29 03:09:30 +08:00
|
|
|
#include <memory>
|
|
|
|
#include <vector>
|
|
|
|
|
|
|
|
namespace lld {
|
|
|
|
namespace coff {
|
|
|
|
|
|
|
|
using llvm::object::Archive;
|
|
|
|
using llvm::object::COFFSymbolRef;
|
2015-05-29 23:45:35 +08:00
|
|
|
using llvm::object::coff_import_header;
|
2015-06-30 08:10:54 +08:00
|
|
|
using llvm::object::coff_symbol_generic;
|
2015-07-10 01:43:50 +08:00
|
|
|
using llvm::object::coff_symbol16;
|
|
|
|
using llvm::object::coff_symbol32;
|
2015-05-29 03:09:30 +08:00
|
|
|
|
|
|
|
class ArchiveFile;
|
2015-06-30 08:47:52 +08:00
|
|
|
class BitcodeFile;
|
2015-05-29 03:09:30 +08:00
|
|
|
class InputFile;
|
|
|
|
class ObjectFile;
|
|
|
|
class SymbolBody;
|
|
|
|
|
|
|
|
// A real symbol object, SymbolBody, is usually accessed indirectly
|
|
|
|
// through a Symbol. There's always one Symbol for each symbol name.
|
|
|
|
// The resolver updates SymbolBody pointers as it resolves symbols.
|
|
|
|
struct Symbol {
|
|
|
|
explicit Symbol(SymbolBody *P) : Body(P) {}
|
2015-07-06 05:54:42 +08:00
|
|
|
std::atomic<SymbolBody *> Body;
|
2015-05-29 03:09:30 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
// The base class for real symbol classes.
|
|
|
|
class SymbolBody {
|
|
|
|
public:
|
|
|
|
enum Kind {
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
// The order of these is significant. We start with the regular defined
|
|
|
|
// symbols as those are the most prevelant and the zero tag is the cheapest
|
|
|
|
// to set. Among the defined kinds, the lower the kind is preferred over
|
|
|
|
// the higher kind when testing wether one symbol should take precedence
|
|
|
|
// over another.
|
|
|
|
DefinedRegularKind = 0,
|
2015-06-20 15:21:57 +08:00
|
|
|
DefinedCommonKind,
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
DefinedLocalImportKind,
|
|
|
|
DefinedImportThunkKind,
|
|
|
|
DefinedImportDataKind,
|
|
|
|
DefinedAbsoluteKind,
|
2015-07-25 06:58:44 +08:00
|
|
|
DefinedRelativeKind,
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
DefinedBitcodeKind,
|
|
|
|
|
2015-06-16 03:06:53 +08:00
|
|
|
UndefinedKind,
|
2015-07-01 03:35:21 +08:00
|
|
|
LazyKind,
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
|
|
|
|
LastDefinedCOFFKind = DefinedCommonKind,
|
|
|
|
LastDefinedKind = DefinedBitcodeKind,
|
2015-05-29 03:09:30 +08:00
|
|
|
};
|
|
|
|
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
Kind kind() const { return static_cast<Kind>(SymbolKind); }
|
2015-05-29 03:09:30 +08:00
|
|
|
|
|
|
|
// Returns true if this is an external symbol.
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
bool isExternal() { return IsExternal; }
|
2015-05-29 03:09:30 +08:00
|
|
|
|
|
|
|
// Returns the symbol name.
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
StringRef getName();
|
2015-05-29 03:09:30 +08:00
|
|
|
|
|
|
|
// A SymbolBody has a backreference to a Symbol. Originally they are
|
|
|
|
// doubly-linked. A backreference will never change. But the pointer
|
|
|
|
// in the Symbol may be mutated by the resolver. If you have a
|
|
|
|
// pointer P to a SymbolBody and are not sure whether the resolver
|
|
|
|
// has chosen the object among other objects having the same name,
|
2015-06-01 11:55:02 +08:00
|
|
|
// you can access P->Backref->Body to get the resolver's result.
|
2015-05-29 03:09:30 +08:00
|
|
|
void setBackref(Symbol *P) { Backref = P; }
|
2015-07-06 05:54:42 +08:00
|
|
|
SymbolBody *repl() { return Backref ? Backref->Body.load() : this; }
|
2015-05-29 03:09:30 +08:00
|
|
|
|
|
|
|
// Decides which symbol should "win" in the symbol table, this or
|
|
|
|
// the Other. Returns 1 if this wins, -1 if the Other wins, or 0 if
|
|
|
|
// they are duplicate (conflicting) symbols.
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
int compare(SymbolBody *Other);
|
2015-05-29 03:09:30 +08:00
|
|
|
|
2015-06-26 07:22:00 +08:00
|
|
|
// Returns a name of this symbol including source file name.
|
|
|
|
// Used only for debugging and logging.
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
std::string getDebugName();
|
2015-06-26 07:22:00 +08:00
|
|
|
|
2015-05-29 03:09:30 +08:00
|
|
|
protected:
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
explicit SymbolBody(Kind K, StringRef N = "")
|
|
|
|
: SymbolKind(K), IsExternal(true), IsCOMDAT(false),
|
|
|
|
IsReplaceable(false), Name(N) {}
|
2015-05-29 03:09:30 +08:00
|
|
|
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
const unsigned SymbolKind : 8;
|
|
|
|
unsigned IsExternal : 1;
|
|
|
|
|
|
|
|
// This bit is used by the \c DefinedRegular subclass.
|
|
|
|
unsigned IsCOMDAT : 1;
|
|
|
|
|
|
|
|
// This bit is used by the \c DefinedBitcode subclass.
|
|
|
|
unsigned IsReplaceable : 1;
|
|
|
|
|
|
|
|
StringRef Name;
|
2015-05-29 03:09:30 +08:00
|
|
|
Symbol *Backref = nullptr;
|
|
|
|
};
|
|
|
|
|
|
|
|
// The base class for any defined symbols, including absolute symbols,
|
|
|
|
// etc.
|
|
|
|
class Defined : public SymbolBody {
|
|
|
|
public:
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
Defined(Kind K, StringRef N = "") : SymbolBody(K, N) {}
|
2015-05-29 03:09:30 +08:00
|
|
|
|
|
|
|
static bool classof(const SymbolBody *S) {
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
return S->kind() <= LastDefinedKind;
|
2015-05-29 03:09:30 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Returns the RVA (relative virtual address) of this symbol. The
|
|
|
|
// writer sets and uses RVAs.
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
uint64_t getRVA();
|
2015-05-29 03:09:30 +08:00
|
|
|
|
|
|
|
// Returns the file offset of this symbol in the final executable.
|
|
|
|
// The writer uses this information to apply relocations.
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
uint64_t getFileOff();
|
2015-07-30 00:30:45 +08:00
|
|
|
|
|
|
|
// Returns the RVA relative to the beginning of the output section.
|
|
|
|
// Used to implement SECREL relocation type.
|
|
|
|
uint64_t getSecrel();
|
|
|
|
|
|
|
|
// Returns the output section index.
|
|
|
|
// Used to implement SECTION relocation type.
|
|
|
|
uint64_t getSectionIndex();
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
};
|
2015-05-29 03:09:30 +08:00
|
|
|
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
// Symbols defined via a COFF object file.
|
|
|
|
class DefinedCOFF : public Defined {
|
|
|
|
friend SymbolBody;
|
|
|
|
public:
|
|
|
|
DefinedCOFF(Kind K, ObjectFile *F, COFFSymbolRef S)
|
2015-06-30 08:10:54 +08:00
|
|
|
: Defined(K), File(F), Sym(S.getGeneric()) {}
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
|
|
|
|
static bool classof(const SymbolBody *S) {
|
|
|
|
return S->kind() <= LastDefinedCOFFKind;
|
|
|
|
}
|
|
|
|
|
2015-07-03 04:33:48 +08:00
|
|
|
int getFileIndex() { return File->Index; }
|
|
|
|
|
2015-07-10 01:43:50 +08:00
|
|
|
COFFSymbolRef getCOFFSymbol();
|
|
|
|
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
protected:
|
|
|
|
ObjectFile *File;
|
2015-06-30 08:10:54 +08:00
|
|
|
const coff_symbol_generic *Sym;
|
2015-05-29 03:09:30 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
// Regular defined symbols read from object file symbol tables.
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
class DefinedRegular : public DefinedCOFF {
|
2015-05-29 03:09:30 +08:00
|
|
|
public:
|
2015-06-26 07:22:00 +08:00
|
|
|
DefinedRegular(ObjectFile *F, COFFSymbolRef S, SectionChunk *C)
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
: DefinedCOFF(DefinedRegularKind, F, S), Data(&C->Ptr) {
|
2015-06-30 08:10:54 +08:00
|
|
|
IsExternal = S.isExternal();
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
IsCOMDAT = C->isCOMDAT();
|
|
|
|
}
|
2015-05-29 03:09:30 +08:00
|
|
|
|
|
|
|
static bool classof(const SymbolBody *S) {
|
|
|
|
return S->kind() == DefinedRegularKind;
|
|
|
|
}
|
|
|
|
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
uint64_t getFileOff() {
|
2015-06-30 08:10:54 +08:00
|
|
|
return (*Data)->getFileOff() + Sym->Value;
|
2015-06-24 12:36:52 +08:00
|
|
|
}
|
|
|
|
|
2015-06-30 08:10:54 +08:00
|
|
|
uint64_t getRVA() { return (*Data)->getRVA() + Sym->Value; }
|
2015-06-26 06:00:42 +08:00
|
|
|
bool isCOMDAT() { return IsCOMDAT; }
|
2015-06-27 02:58:24 +08:00
|
|
|
bool isLive() const { return (*Data)->isLive(); }
|
2015-06-26 06:00:42 +08:00
|
|
|
void markLive() { (*Data)->markLive(); }
|
[opt] Replace the recursive walk for GC with a worklist algorithm.
This flattens the entire liveness walk from a recursive mark approach to
a worklist approach. It also sinks the worklist management completely
out of the SectionChunk and into the Writer by exposing the ability to
iterato over children of a chunk and over the symbol bodies of relocated
symbols. I'm not 100% happy with the API names, so suggestions welcome
there.
This allows us to use a single worklist for the entire recursive walk
and would also be a natural place to take advantage of parallelism at
some future point.
With this, we completely inline away the GC walk into the
Writer::markLive function and it makes it very easy to profile what is
slow. Currently, time is being wasted checking whether a Chunk isa
SectionChunk (it essentially always is), finding (or skipping)
a replacement for a symbol, and chasing pointers between symbols and
their chunks. There are a bunch of things we can do to fix this, and its
easier to do them after this change IMO.
This change alone saves 1-2% of the time for my self-link of lld.exe
(which I'm running and benchmarking on Linux ironically).
Perhaps more notably, we'll no longer blow out the stack for large
links. =]
Just as an FYI, at this point, I/O is starting to really dominate the
profile. Well over 10% of the time appears to be inside the kernel doing
page table silliness. I think a decent chunk of this can be nuked as
well, but it's a little odd as cross-linking in this way isn't really
the primary goal here.
Differential Revision: http://reviews.llvm.org/D10790
llvm-svn: 240995
2015-06-30 05:12:49 +08:00
|
|
|
SectionChunk *getChunk() { return *Data; }
|
2015-06-30 08:10:54 +08:00
|
|
|
uint32_t getValue() { return Sym->Value; }
|
2015-05-29 03:09:30 +08:00
|
|
|
|
2015-06-20 15:21:57 +08:00
|
|
|
private:
|
2015-06-26 06:00:42 +08:00
|
|
|
SectionChunk **Data;
|
2015-06-20 15:21:57 +08:00
|
|
|
};
|
|
|
|
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
class DefinedCommon : public DefinedCOFF {
|
2015-06-20 15:21:57 +08:00
|
|
|
public:
|
2015-06-26 07:22:00 +08:00
|
|
|
DefinedCommon(ObjectFile *F, COFFSymbolRef S, CommonChunk *C)
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
: DefinedCOFF(DefinedCommonKind, F, S), Data(C) {
|
2015-06-30 08:10:54 +08:00
|
|
|
IsExternal = S.isExternal();
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
}
|
2015-06-20 15:21:57 +08:00
|
|
|
|
|
|
|
static bool classof(const SymbolBody *S) {
|
|
|
|
return S->kind() == DefinedCommonKind;
|
|
|
|
}
|
|
|
|
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
uint64_t getRVA() { return Data->getRVA(); }
|
|
|
|
uint64_t getFileOff() { return Data->getFileOff(); }
|
2015-05-29 03:09:30 +08:00
|
|
|
|
|
|
|
private:
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
friend SymbolBody;
|
|
|
|
|
2015-06-30 08:10:54 +08:00
|
|
|
uint64_t getSize() { return Sym->Value; }
|
2015-06-20 15:21:57 +08:00
|
|
|
|
2015-06-26 03:10:58 +08:00
|
|
|
CommonChunk *Data;
|
2015-05-29 03:09:30 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
// Absolute symbols.
|
|
|
|
class DefinedAbsolute : public Defined {
|
|
|
|
public:
|
2015-06-26 11:09:23 +08:00
|
|
|
DefinedAbsolute(StringRef N, COFFSymbolRef S)
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
: Defined(DefinedAbsoluteKind, N), VA(S.getValue()) {
|
|
|
|
IsExternal = S.isExternal();
|
|
|
|
}
|
2015-06-26 11:09:23 +08:00
|
|
|
|
|
|
|
DefinedAbsolute(StringRef N, uint64_t V)
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
: Defined(DefinedAbsoluteKind, N), VA(V) {}
|
2015-05-29 03:09:30 +08:00
|
|
|
|
|
|
|
static bool classof(const SymbolBody *S) {
|
|
|
|
return S->kind() == DefinedAbsoluteKind;
|
|
|
|
}
|
|
|
|
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
uint64_t getRVA() { return VA - Config->ImageBase; }
|
2015-07-25 07:51:14 +08:00
|
|
|
void setVA(uint64_t V) { VA = V; }
|
2015-05-29 03:09:30 +08:00
|
|
|
|
|
|
|
private:
|
2015-06-26 11:09:23 +08:00
|
|
|
uint64_t VA;
|
2015-05-29 03:09:30 +08:00
|
|
|
};
|
|
|
|
|
2015-07-25 06:58:44 +08:00
|
|
|
// This is a kind of absolute symbol but relative to the image base.
|
|
|
|
// Unlike absolute symbols, relocations referring this kind of symbols
|
|
|
|
// are subject of the base relocation. This type is used rarely --
|
|
|
|
// mainly for __ImageBase.
|
|
|
|
class DefinedRelative : public Defined {
|
|
|
|
public:
|
|
|
|
explicit DefinedRelative(StringRef Name, uint64_t V = 0)
|
|
|
|
: Defined(DefinedRelativeKind, Name), RVA(V) {}
|
|
|
|
|
|
|
|
static bool classof(const SymbolBody *S) {
|
|
|
|
return S->kind() == DefinedRelativeKind;
|
|
|
|
}
|
|
|
|
|
|
|
|
uint64_t getRVA() { return RVA; }
|
|
|
|
void setRVA(uint64_t V) { RVA = V; }
|
|
|
|
|
|
|
|
private:
|
|
|
|
uint64_t RVA;
|
|
|
|
};
|
|
|
|
|
2015-05-29 03:09:30 +08:00
|
|
|
// This class represents a symbol defined in an archive file. It is
|
|
|
|
// created from an archive file header, and it knows how to load an
|
|
|
|
// object file from an archive to replace itself with a defined
|
|
|
|
// symbol. If the resolver finds both Undefined and Lazy for
|
|
|
|
// the same name, it will ask the Lazy to load a file.
|
|
|
|
class Lazy : public SymbolBody {
|
|
|
|
public:
|
|
|
|
Lazy(ArchiveFile *F, const Archive::Symbol S)
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
: SymbolBody(LazyKind, S.getName()), File(F), Sym(S) {}
|
2015-05-29 03:09:30 +08:00
|
|
|
|
|
|
|
static bool classof(const SymbolBody *S) { return S->kind() == LazyKind; }
|
|
|
|
|
|
|
|
// Returns an object file for this symbol, or a nullptr if the file
|
|
|
|
// was already returned.
|
|
|
|
ErrorOr<std::unique_ptr<InputFile>> getMember();
|
|
|
|
|
2015-07-03 04:33:48 +08:00
|
|
|
int getFileIndex() { return File->Index; }
|
|
|
|
|
2015-05-29 03:09:30 +08:00
|
|
|
private:
|
|
|
|
ArchiveFile *File;
|
|
|
|
const Archive::Symbol Sym;
|
|
|
|
};
|
|
|
|
|
|
|
|
// Undefined symbols.
|
|
|
|
class Undefined : public SymbolBody {
|
|
|
|
public:
|
2015-07-02 06:32:23 +08:00
|
|
|
explicit Undefined(StringRef N) : SymbolBody(UndefinedKind, N) {}
|
2015-05-29 03:09:30 +08:00
|
|
|
|
|
|
|
static bool classof(const SymbolBody *S) {
|
|
|
|
return S->kind() == UndefinedKind;
|
|
|
|
}
|
|
|
|
|
|
|
|
// An undefined symbol can have a fallback symbol which gives an
|
|
|
|
// undefined symbol a second chance if it would remain undefined.
|
|
|
|
// If it remains undefined, it'll be replaced with whatever the
|
|
|
|
// Alias pointer points to.
|
2015-07-04 06:03:36 +08:00
|
|
|
SymbolBody *WeakAlias = nullptr;
|
2015-07-04 13:28:41 +08:00
|
|
|
|
|
|
|
// If this symbol is external weak, try to resolve it to a defined
|
|
|
|
// symbol by searching the chain of fallback symbols. Returns the symbol if
|
|
|
|
// successful, otherwise returns null.
|
|
|
|
Defined *getWeakAlias();
|
2015-05-29 03:09:30 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
// Windows-specific classes.
|
|
|
|
|
2015-05-29 23:49:09 +08:00
|
|
|
// This class represents a symbol imported from a DLL. This has two
|
|
|
|
// names for internal use and external use. The former is used for
|
|
|
|
// name resolution, and the latter is used for the import descriptor
|
|
|
|
// table in an output. The former has "__imp_" prefix.
|
|
|
|
class DefinedImportData : public Defined {
|
|
|
|
public:
|
2015-06-09 03:43:59 +08:00
|
|
|
DefinedImportData(StringRef D, StringRef N, StringRef E,
|
2015-05-29 23:49:09 +08:00
|
|
|
const coff_import_header *H)
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
: Defined(DefinedImportDataKind, N), DLLName(D), ExternalName(E), Hdr(H) {
|
|
|
|
}
|
2015-05-29 23:49:09 +08:00
|
|
|
|
|
|
|
static bool classof(const SymbolBody *S) {
|
|
|
|
return S->kind() == DefinedImportDataKind;
|
|
|
|
}
|
|
|
|
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
uint64_t getRVA() { return Location->getRVA(); }
|
|
|
|
uint64_t getFileOff() { return Location->getFileOff(); }
|
|
|
|
|
2015-05-29 23:49:09 +08:00
|
|
|
StringRef getDLLName() { return DLLName; }
|
2015-06-02 05:05:27 +08:00
|
|
|
StringRef getExternalName() { return ExternalName; }
|
2015-05-29 23:49:09 +08:00
|
|
|
void setLocation(Chunk *AddressTable) { Location = AddressTable; }
|
|
|
|
uint16_t getOrdinal() { return Hdr->OrdinalHint; }
|
|
|
|
|
|
|
|
private:
|
|
|
|
StringRef DLLName;
|
2015-06-02 05:05:27 +08:00
|
|
|
StringRef ExternalName;
|
2015-05-29 23:49:09 +08:00
|
|
|
const coff_import_header *Hdr;
|
|
|
|
Chunk *Location = nullptr;
|
|
|
|
};
|
|
|
|
|
2015-05-29 03:09:30 +08:00
|
|
|
// This class represents a symbol for a jump table entry which jumps
|
|
|
|
// to a function in a DLL. Linker are supposed to create such symbols
|
|
|
|
// without "__imp_" prefix for all function symbols exported from
|
|
|
|
// DLLs, so that you can call DLL functions as regular functions with
|
|
|
|
// a regular name. A function pointer is given as a DefinedImportData.
|
|
|
|
class DefinedImportThunk : public Defined {
|
|
|
|
public:
|
2015-07-26 05:54:50 +08:00
|
|
|
DefinedImportThunk(StringRef Name, DefinedImportData *S, uint16_t Machine);
|
2015-05-29 03:09:30 +08:00
|
|
|
|
|
|
|
static bool classof(const SymbolBody *S) {
|
|
|
|
return S->kind() == DefinedImportThunkKind;
|
|
|
|
}
|
|
|
|
|
2015-07-25 09:16:06 +08:00
|
|
|
uint64_t getRVA() { return Data->getRVA(); }
|
|
|
|
uint64_t getFileOff() { return Data->getFileOff(); }
|
|
|
|
Chunk *getChunk() { return Data.get(); }
|
2015-05-29 03:09:30 +08:00
|
|
|
|
|
|
|
private:
|
2015-07-25 09:16:06 +08:00
|
|
|
std::unique_ptr<Chunk> Data;
|
2015-05-29 03:09:30 +08:00
|
|
|
};
|
|
|
|
|
2015-06-25 11:31:47 +08:00
|
|
|
// If you have a symbol "__imp_foo" in your object file, a symbol name
|
|
|
|
// "foo" becomes automatically available as a pointer to "__imp_foo".
|
|
|
|
// This class is for such automatically-created symbols.
|
|
|
|
// Yes, this is an odd feature. We didn't intend to implement that.
|
|
|
|
// This is here just for compatibility with MSVC.
|
|
|
|
class DefinedLocalImport : public Defined {
|
|
|
|
public:
|
|
|
|
DefinedLocalImport(StringRef N, Defined *S)
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
: Defined(DefinedLocalImportKind, N), Data(S) {}
|
2015-06-25 11:31:47 +08:00
|
|
|
|
|
|
|
static bool classof(const SymbolBody *S) {
|
|
|
|
return S->kind() == DefinedLocalImportKind;
|
|
|
|
}
|
|
|
|
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
uint64_t getRVA() { return Data.getRVA(); }
|
|
|
|
uint64_t getFileOff() { return Data.getFileOff(); }
|
|
|
|
|
2015-06-25 11:31:47 +08:00
|
|
|
Chunk *getChunk() { return &Data; }
|
|
|
|
|
|
|
|
private:
|
|
|
|
LocalImportChunk Data;
|
|
|
|
};
|
|
|
|
|
2015-06-02 04:10:10 +08:00
|
|
|
class DefinedBitcode : public Defined {
|
2015-06-30 08:47:52 +08:00
|
|
|
friend SymbolBody;
|
2015-06-02 04:10:10 +08:00
|
|
|
public:
|
2015-06-30 08:47:52 +08:00
|
|
|
DefinedBitcode(BitcodeFile *F, StringRef N, bool IsReplaceable)
|
|
|
|
: Defined(DefinedBitcodeKind, N), File(F) {
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
this->IsReplaceable = IsReplaceable;
|
|
|
|
}
|
2015-06-02 04:10:10 +08:00
|
|
|
|
|
|
|
static bool classof(const SymbolBody *S) {
|
|
|
|
return S->kind() == DefinedBitcodeKind;
|
|
|
|
}
|
2015-06-30 08:47:52 +08:00
|
|
|
|
|
|
|
private:
|
|
|
|
BitcodeFile *File;
|
2015-06-02 04:10:10 +08:00
|
|
|
};
|
|
|
|
|
2015-07-14 06:01:27 +08:00
|
|
|
inline uint64_t Defined::getRVA() {
|
|
|
|
switch (kind()) {
|
|
|
|
case DefinedAbsoluteKind:
|
|
|
|
return cast<DefinedAbsolute>(this)->getRVA();
|
2015-07-25 06:58:44 +08:00
|
|
|
case DefinedRelativeKind:
|
|
|
|
return cast<DefinedRelative>(this)->getRVA();
|
2015-07-14 06:01:27 +08:00
|
|
|
case DefinedImportDataKind:
|
|
|
|
return cast<DefinedImportData>(this)->getRVA();
|
|
|
|
case DefinedImportThunkKind:
|
|
|
|
return cast<DefinedImportThunk>(this)->getRVA();
|
|
|
|
case DefinedLocalImportKind:
|
|
|
|
return cast<DefinedLocalImport>(this)->getRVA();
|
|
|
|
case DefinedCommonKind:
|
|
|
|
return cast<DefinedCommon>(this)->getRVA();
|
|
|
|
case DefinedRegularKind:
|
|
|
|
return cast<DefinedRegular>(this)->getRVA();
|
|
|
|
case DefinedBitcodeKind:
|
|
|
|
llvm_unreachable("There is no address for a bitcode symbol.");
|
|
|
|
case LazyKind:
|
|
|
|
case UndefinedKind:
|
|
|
|
llvm_unreachable("Cannot get the address for an undefined symbol.");
|
|
|
|
}
|
|
|
|
llvm_unreachable("unknown symbol kind");
|
|
|
|
}
|
|
|
|
|
2015-05-29 03:09:30 +08:00
|
|
|
} // namespace coff
|
|
|
|
} // namespace lld
|
|
|
|
|
2015-07-07 01:45:22 +08:00
|
|
|
// Support isa<>, cast<> and dyn_cast<> for Symbol::Body.
|
|
|
|
namespace llvm {
|
|
|
|
template <typename T>
|
|
|
|
struct simplify_type<std::atomic<T *>> {
|
|
|
|
typedef T *SimpleType;
|
|
|
|
static T *getSimplifiedValue(std::atomic<T *> &A) { return A.load(); }
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
2015-05-29 03:09:30 +08:00
|
|
|
#endif
|