| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds reportError to MCContext, which can be used as an alternative to
reportFatalError when the assembler wants to try to continue processing the
rest of the file after the error is reported, so that all of the errors ina
file can be reported. It records the fact that an error was encountered, so we
can avoid emitting an object file if any errors occurred.
This patch doesn't add any uses of this function (a later patch will convert
most uses of reportFatalError to use it), but there is a small functional
change: we use the SourceManager to print the error message, even if we have a
null SMLoc. This means that we get a SourceManager-style message, with the file
and line information shown as <unknown>, rather than the "LLVM ERROR" style
used by report_fatal_error.
llvm-svn: 253327
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The way prelink used to work was
* The compiler decides if a given section only has relocations that
are know to point to the same DSO. If so, it names it
.data.rel.ro.local<something>.
* The static linker puts all of these together.
* The prelinker program assigns addresses to each library and resolves
the local relocations.
There are many problems with this:
* It is incompatible with address space randomization.
* The information passed by the compiler is redundant. The linker
knows if a given relocation is in the same DSO or not. If could sort
by that if so desired.
* There are newer ways of speeding up DSO (gnu hash for example).
* Even if we want to implement this again in the compiler, the previous
implementation is pretty broken. It talks about relocations that are
"resolved by the static linker". If they are resolved, there are none
left for the prelinker. What one needs to track is if an expression
will require only dynamic relocations that point to the same DSO.
At this point it looks like the prelinker is an historical curiosity.
For example, fedora has retired it because it failed to build for two
releases
(http://pkgs.fedoraproject.org/cgit/prelink.git/commit/?id=eb43100a8331d91c801ee3dcdb0a0bb9babfdc1f)
This patch removes support for it. That is, it stops printing the
".local" sections.
llvm-svn: 253280
|
|
|
|
|
|
|
|
|
|
| |
Storing the source location of the expression that created a constant pool
entry allows us to emit better error messages if we later discover that the
expression cannot be represented by a relocation.
Differential Revision: http://reviews.llvm.org/D14646
llvm-svn: 253220
|
|
|
|
|
|
|
| |
This allows for accurate architecture targeting as well as removing
duplicate information (hardcoded feature strings) from MCTargetDesc.
llvm-svn: 253196
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MCRelaxableFragment previously kept a copy of MCSubtargetInfo and
MCInst to enable re-encoding the MCInst later during relaxation. A copy
of MCSubtargetInfo (instead of a reference or pointer) was needed
because the feature bits could be modified by the parser.
This commit replaces the MCSubtargetInfo copy in MCRelaxableFragment
with a constant reference to MCSubtargetInfo. The copies of
MCSubtargetInfo are kept in MCContext, and the target parsers are now
responsible for asking MCContext to provide a copy whenever the feature
bits of MCSubtargetInfo have to be toggled.
With this patch, I saw a 4% reduction in peak memory usage when I
compiled verify-uselistorder.lto.bc using llc.
rdar://problem/21736951
Differential Revision: http://reviews.llvm.org/D14346
llvm-svn: 253127
|
|
|
|
|
|
|
|
|
|
| |
MCSubtargetInfo in the subclasses into MCTargetAsmParser and define a
member function getSTI.
This is done in preparation for making changes to shrink the size of
MCRelaxableFragment. (see http://reviews.llvm.org/D14346).
llvm-svn: 253124
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
R_MIPS_32.
Summary:
Support for R_MIPS_NONE allows us to parse MIPS16's usage of .reloc.
R_MIPS_32 was included to be able to better test the directive.
Targets can add their relocations by overriding MCAsmBackend::getFixupKind().
Subscribers: grosbach, rafael, majnemer, dsanders, llvm-commits
Differential Revision: http://reviews.llvm.org/D13659
llvm-svn: 252888
|
|
|
|
|
|
|
| |
Follow-up to r235963: this matches other assemblers and is less
unexpected (e.g. PR23227).
llvm-svn: 252681
|
|
|
|
| |
llvm-svn: 252439
|
|
|
|
|
|
|
|
| |
assignment parsing to be hooked by target. Allow target to specify if identifier is a label.
Differential Revision: http://reviews.llvm.org/D14255
llvm-svn: 252435
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14252
llvm-svn: 252432
|
|
|
|
|
|
|
|
|
|
| |
We now create the .eh_frame section early, just like every other special
section.
This means that the special flags are visible in code that explicitly
asks for ".eh_frame".
llvm-svn: 252313
|
|
|
|
|
|
|
|
| |
This reverts commit r252305.
Investigating a test failure.
llvm-svn: 252306
|
|
|
|
| |
llvm-svn: 252305
|
|
|
|
| |
llvm-svn: 252304
|
|
|
|
|
|
|
| |
That is the ABI required type. Linkers still check the section name, so
everything should still work.
llvm-svn: 252300
|
|
|
|
| |
llvm-svn: 252299
|
|
|
|
| |
llvm-svn: 252271
|
|
|
|
| |
llvm-svn: 252270
|
|
|
|
| |
llvm-svn: 252260
|
|
|
|
| |
llvm-svn: 252246
|
|
|
|
| |
llvm-svn: 252243
|
|
|
|
| |
llvm-svn: 252241
|
|
|
|
| |
llvm-svn: 252237
|
|
|
|
|
|
| |
It is pretty simple now that the yak is shaved.
llvm-svn: 252105
|
|
|
|
| |
llvm-svn: 252102
|
|
|
|
|
|
|
| |
We now always create the fragment, which lets us handle things like .org after
a .align.
llvm-svn: 252101
|
|
|
|
|
|
|
|
| |
Fixed warnings are: modernize-use-override, modernize-use-nullptr and modernize-redundant-void-arg.
Differential revision: http://reviews.llvm.org/D14312
llvm-svn: 252087
|
|
|
|
|
|
|
| |
We are long past the time when this much bug for bug compatibility was
useful.
llvm-svn: 251970
|
|
|
|
| |
llvm-svn: 251960
|
|
|
|
|
|
|
|
| |
We now create them as they are found and use higher level APIs.
This is a step in avoiding creating unnecessary sections.
llvm-svn: 251958
|
|
|
|
| |
llvm-svn: 251952
|
|
|
|
|
|
|
|
| |
Remove code that was assuming that this would never work.
Thanks to Colin LeMahie for finding and diagnosing the bug.
llvm-svn: 251818
|
|
|
|
| |
llvm-svn: 251573
|
|
|
|
|
|
|
|
| |
These MachO file directives are used by linkers and other tools to provide
compatibility information, much like the existing .ios_version_min and
.macosx_version_min.
llvm-svn: 251569
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The existing behavior was correct on Darwin, which is probably the
platform it was written for.
Before this change, we would rewrite "align 8" to ".align 3" and then
fail to make it through the integrated assembler because 3 is not a
power of 2.
Differential Revision: http://reviews.llvm.org/D14120
llvm-svn: 251418
|
|
|
|
|
|
| |
`qsort` as a file-scope local function name was confusing.
llvm-svn: 251414
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a patch to improve StringTableBuilder's performance. That class'
finalize function is very hot particularly in LLD because the function
does tail-merge strings in string tables or SHF_MERGE sections.
Generic std::sort-style sorter is not efficient for sorting strings.
The function implemented in this patch seems to be more efficient.
Here's a benchmark of LLD to link Clang with or without this patch.
The numbers are medians of 50 runs.
-O0
real 0m0.455s
real 0m0.430s (5.5% faster)
-O3
real 0m0.487s
real 0m0.452s (7.2% faster)
Since that is a benchmark of the whole linker, the speedup of
StringTableBuilder itself is much more than that.
http://reviews.llvm.org/D14053
llvm-svn: 251337
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In PIC mode we were previously computing global variable addresses (or GOT
entry addresses) by adding the PC, the PC-relative GOT displacement and
the GOT-relative symbol/GOT entry displacement. Because the latter two
displacements are fixed, we ended up performing one more addition than
necessary.
This change causes us to compute addresses using a single PC-relative
displacement, resulting in a shorter code sequence. This reduces code size
by about 4% in a recent build of Chromium for Android.
As a result of this change we no longer need to compute the GOT base address
in the ARM backend, which allows us to remove the Global Base Reg pass and
SDAG lowering for the GOT.
We also now no longer use the GOT when addressing a symbol which is known
to be defined in the same linkage unit. Specifically, the symbol must have
either hidden visibility or a strong definition in the current module in
order to not use the the GOT.
This is a change from the previous behaviour where we would use the GOT to
address externally visible symbols defined in the same module. I think the
only cases where this could matter are cases involving symbol interposition,
but we don't really support that well anyway.
Differential Revision: http://reviews.llvm.org/D13650
llvm-svn: 251322
|
|
|
|
|
|
|
|
|
|
| |
GNU as and Darwin give the various binary operators different
precedence. LLVM's MC supported the Darwin semantics but not the GNU
semantics.
This fixes PR25311.
llvm-svn: 251271
|
|
|
|
|
|
|
|
|
|
|
|
| |
In this mode it just tries to tail merge the strings without imposing any other
format constrains. It will not, for example, add a null byte between them.
Also add support for keeping a tentative size and offset if we decide to
not optimize after all.
This will be used shortly in lld for merging SHF_STRINGS sections.
llvm-svn: 251153
|
|
|
|
| |
llvm-svn: 251143
|
|
|
|
|
|
| |
This was only use in the extremely uncommon case of @@@ symbols on ELF.
llvm-svn: 251039
|
|
|
|
| |
llvm-svn: 251030
|
|
|
|
| |
llvm-svn: 251024
|
|
|
|
| |
llvm-svn: 251023
|
|
|
|
| |
llvm-svn: 250614
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Crashing is bad, m'kay? Fixing a 4 year old bug of my own creation.
Adding the testcase now which I should have added then which would have
long since caught this.
The problem is that printMessage() will display the diagnostic but not
set HadError to true, resulting in the assembler continuing on its way
and trying to create relocations for things that may not allow them or
otherwise get itself into trouble. Using the Error() helper function
here rather than calling printMessage() directly resolves this.
rdar://23133240
llvm-svn: 250557
|
|
|
|
| |
llvm-svn: 250425
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Recommit r250342: move coal-sections-powerpc.s to subdirectory for powerpc.
Some background on why we don't have to use *coal* sections anymore:
Long ago when C++ was new and "weak" had not been standardized, an attempt was
made in cctools to support C++ inlines that can be coalesced by putting them
into their own section (TEXT/textcoal_nt instead of TEXT/text).
The current macho linker supports the weak-def bit on any symbol to allow it to
be coalesced, but the compiler still puts weak-def functions/data into alternate
section names, which the linker must map back to the base section name.
This patch makes changes that are necessary to prevent the compiler from using
the "coal" sections and have it use the non-coal sections instead when the
target architecture is not powerpc:
TEXT/textcoal_nt instead use TEXT/text
TEXT/const_coal instead use TEXT/const
DATA/datacoal_nt instead use DATA/data
If the target is powerpc, we continue to use the *coal* sections since anyone
targeting powerpc is probably using an old linker that doesn't have support for
the weak-def bits.
Also, have the assembler issue a warning if it encounters a *coal* section in
the assembly file and inform the users to use the non-coal sections instead.
rdar://problem/14265330
Differential Revision: http://reviews.llvm.org/D13188
llvm-svn: 250370
|