Summary:
This change is part of a series of commits dedicated to have a
single DataLayout during compilation by using always the one owned by the
module.
Reviewers: echristo
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10984
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241610 91177308-0d34-0410-b5e6-96231b3b80d8
getSymbolValue now returns a value that in convenient for most callers:
* 0 for undefined
* symbol size for common symbols
* offset/address for symbols the rest
Code that needs something more specific can check getSymbolFlags.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241605 91177308-0d34-0410-b5e6-96231b3b80d8
This commit adds a 'run-pass' option to llc, which instructs the compiler to run
one specific code generation pass only.
Llc already has the 'start-after' and the 'stop-after' options, and this new
option complements the other two by making it easier to write tests that want
to invoke a single pass only.
Reviewers: Duncan P. N. Exon Smith
Differential Revision: http://reviews.llvm.org/D10776
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241476 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This concludes the patch series to eliminate StringRef forms of GNU triples
from the internals of LLVM that began in r239036.
At this point, the StringRef-form of GNU Triples should only be used in the
public API (including IR serialization) and a couple objects that directly
interact with the API (most notably the Module class). The next step is to
replace these Triple objects with the TargetTuple object that will represent
our authoratative/unambiguous internal equivalent to GNU Triples.
Reviewers: rengolin
Subscribers: llvm-commits, jholewinski, ted, rengolin
Differential Revision: http://reviews.llvm.org/D10962
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241472 91177308-0d34-0410-b5e6-96231b3b80d8
This change includes a fix for https://code.google.com/p/chromium/issues/detail?id=499508#c3,
which required updating the visibility for symbols with eliminated definitions.
--Original Commit Message--
Add new EliminateAvailableExternally module pass, which is performed in
O2 compiles just before GlobalDCE, unless we are preparing for LTO.
This pass eliminates available externally globals (turning them into
declarations), regardless of whether they are dead/unreferenced, since
we are guaranteed to have a copy available elsewhere at link time.
This enables additional opportunities for GlobalDCE.
If we are preparing for LTO (e.g. a -flto -c compile), the pass is not
included as we want to preserve available externally functions for possible
link time inlining. The FE indicates whether we are doing an -flto compile
via the new PrepareForLTO flag on the PassManagerBuilder.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241466 91177308-0d34-0410-b5e6-96231b3b80d8
Originally added in r139314.
Back then it didn't actually get the address, it got whatever value the
relocation used: address or offset.
The values in different object formats are:
* MachO: Always an offset.
* COFF: Always an address, but when talking about the virtual address of
sections it says: "for simplicity, compilers should set this to zero".
* ELF: An offset for .o files and and address for .so files. In the case of the
.so, the relocation in not linked to any section (sh_info is 0). We can't
really compute an offset.
Some API mappings would be:
* Use getAddress for everything. It would be quite cumbersome. To compute the
address elf has to follow sh_info, which can be corrupted and therefore the
method has to return an ErrorOr. The address of the section is also the same
for every relocation in a section, so we shouldn't have to check the error
and fetch the value for every relocation.
* Use a getValue and make it up to the user to know what it is getting.
* Use a getOffset and:
* Assert for dynamic ELF objects. That is a very peculiar case and it is
probably fair to ask any tool that wants to support it to use ELF.h. The
only tool we have that reads those (llvm-readobj) already does that. The
only other use case I can think of is a dynamic linker.
* Check that COFF .obj files have sections with zero virtual address spaces. If
it turns out that some assembler/compiler produces these, we can change
COFFObjectFile::getRelocationOffset to subtract it. Given COFF format,
this can be done without the need for ErrorOr.
The getRelocationAddress method was never implemented for COFF. It also
had exactly one use in a very peculiar case: a shortcut for adding the
section value to a pcrel reloc on MachO.
Given that, I don't expect that there is any use out there of the C API. If
that is not the case, let me know and I will add it back with the implementation
inlined and do a proper deprecation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241450 91177308-0d34-0410-b5e6-96231b3b80d8
From the linker's perspective, an available_externally global is equivalent
to an external declaration (per isDeclarationForLinker()), so it is incorrect
to consider it to be a weak definition.
Also clean up some logic in the dead argument elimination pass and clarify
its comments to better explain how its behavior depends on linkage,
introduce GlobalValue::isStrongDefinitionForLinker() and start using
it throughout the optimizers and backend.
Differential Revision: http://reviews.llvm.org/D10941
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241413 91177308-0d34-0410-b5e6-96231b3b80d8
There is some functional change here because it changes target code from
atoi(3) to StringRef::getAsInteger which has error checking. For valid
constraints there should be no difference.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241411 91177308-0d34-0410-b5e6-96231b3b80d8
This is needed for COFF linkers to distinguish between weak external aliases
and regular symbols with LLVM weak linkage, which are represented as strong
symbols in COFF.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241389 91177308-0d34-0410-b5e6-96231b3b80d8
SHT_NOBITS sections do not have content in an object file. Now the yaml2obj
tool does not accept `Content` field for such sections, and the obj2yaml
tool does not attempt to read the section content from a file.
Restore r241350 and r241352.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241377 91177308-0d34-0410-b5e6-96231b3b80d8
r241350 broke lld tests.
r241352 depends on r241350.
Original messages:
"[ELFYAML] Fix handling SHT_NOBITS sections by obj2yaml/yaml2obj tools"
"[ELFYAML] Make the Size field for .bss section optional"
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241354 91177308-0d34-0410-b5e6-96231b3b80d8
SHT_NOBITS sections do not have content in an object file. Now yaml2obj
tool does not accept `Content` field for such sections, and obj2yaml
tool does not attempt to read the section content from a file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241350 91177308-0d34-0410-b5e6-96231b3b80d8
The ELFObjectFile now just reasons about a section/index pair, removing
one of the users that force ELF.h to maintain the difference.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241344 91177308-0d34-0410-b5e6-96231b3b80d8
This commit changes normal isel and fast isel to read the user-defined trap
function name from function attribute "trap-func-name" attached to llvm.trap or
llvm.debugtrap instead of from TargetOptions::TrapFuncName. This is needed to
use clang's command line option "-ftrap-function" for LTO and enable changing
the trap function name on a per-call-site basis.
Out-of-tree projects currently using TargetOptions::TrapFuncName to specify the
trap function name should attach attribute "trap-func-name" to the call sites
of llvm.trap and llvm.debugtrap instead.
rdar://problem/21225723
Differential Revision: http://reviews.llvm.org/D10832
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241305 91177308-0d34-0410-b5e6-96231b3b80d8
This change is needed later when I make changes to attach string function
attributes to llvm.trap and llvm.debugtrap.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241304 91177308-0d34-0410-b5e6-96231b3b80d8
This function can really fail since the string table offset can be out of
bounds.
Using ErrorOr makes sure the error is checked.
Hopefully a lot of the boilerplate code in tools/* can go away once we have
a diagnostic manager in Object.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241297 91177308-0d34-0410-b5e6-96231b3b80d8
This patch changes linkage with dbghlp.dll for clang from static (at load time)
to on demand (at the first use of required functions). Clang uses dbghlp.dll
only in minor use-cases. First of all in case of crash and in case of plugin load.
The dbghlp.dll library can be absent on system. In this case clang will fail
to load. With lazy load of dbghlp.dll clang can work even if dbghlp.dll
is not available.
Differential Revision: http://reviews.llvm.org/D10737
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241271 91177308-0d34-0410-b5e6-96231b3b80d8
By default, the GraphWriter code assumes that the generic file open
program (`open` on Apple, `xdg-open` on other systems) can wait on the
forked proces to complete. When the fork ends, the code would delete
the temporary dot files created, and return.
On GNU/Linux, the xdg-open program does not have a "wait for your fork
to complete before dying" option. So the behaviour was that xdg-open
would launch a process, quickly die itself, and then the GraphWriter
code would think its OK to quickly delete all the temporary files.
Once the temporary files were deleted, the dot viewers would get very
upset, and often give you weird errors.
This change only waits on the generic open program on Apple platforms.
Elsewhere, we don't wait on the process, and hence we don't try and
clean up the temporary files.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241250 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This allows the "if (Statepoint SP = Statepoint(I))" idiom.
(I don't think this change needs review, this was uploaded to
phabricator to provide context for later dependent changes.)
Differential Revision: http://reviews.llvm.org/D10629
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241232 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Introduce a simple accessor to get the gc_result hanging off of a
statepoint.
(I don't think this change needs review, this was uploaded to
phabricator to provide context for later dependent changes.)
Differential Revision: http://reviews.llvm.org/D10627
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241231 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch changes the way APInt is compared with a value of type uint64_t.
Before the uint64_t value was truncated to the size of APInt before comparison.
Now the comparison takes into account full 64-bit precision.
Test Plan: Unit tests added. No regressions. Self-hosted check-all done as well.
Reviewers: chandlerc, dexonsmith
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10655
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241204 91177308-0d34-0410-b5e6-96231b3b80d8
