This is relative to PR33173,
Previously if something wrong happened on DWARF parsers side during parsing
object for building gdb index (like was in PR: unsupported relocation)
then LLD continued and finished the link. DWARF parsers sure showed error
message on their side, but that is all.
Patch changes behavior to fail the link in this case and show more
detailed message.
Differential revision: https://reviews.llvm.org/D34814
llvm-svn: 307370
requirements in protocol/class/category declarations
The unguarded availability warnings in the protocol requirements of a protocol
/class/category declaration can be avoided. This matches the behaviour of
Swift's diagnostics. The warnings for deprecated/unavailable protocols are
preserved.
rdar://33156429
Differential Revision: https://reviews.llvm.org/D35061
llvm-svn: 307368
The assignAddresses() function accumulates state in the LinkerScript that
prevents it from being called multiple times. This change moves the state
into a separate structure AddressState that is created at the start of the
function and disposed of at the end.
CurAddressState is used rather than passing a reference to the state as a
parameter to the functions used by assignAddresses(). This is because the
getSymbolValue function needs to be executed in the context of AddressState
but it is stored in ScriptParser when AddressState is not available.
The AddressState is also used in a limited context by processCommands()
Differential Revision: https://reviews.llvm.org/D34345
llvm-svn: 307367
We lower to a sequence consisting of:
- MOVi 0 into a register
- VCMPS to do the actual comparison and set the VFP flags
- FMSTAT to move the flags out of the VFP unit
- MOVCCi to either use the "zero register" that we have previously set
with the MOVi, or move 1 into the result register, based on the values
of the flags
As was the case with soft-float, for some predicates (one, ueq) we
actually need two comparisons instead of just one. When that happens, we
generate two VCMPS-FMSTAT-MOVCCi sequences and chain them by means of
using the result of the first MOVCCi as the "zero register" for the
second one. This is a bit overkill, since one comparison followed by
two non-flag-setting conditional moves should be enough. In any case,
the backend manages to CSE one of the comparisons away so it doesn't
matter much.
Note that unlike SelectionDAG and FastISel, we always use VCMPS, and not
VCMPES. This makes the code a lot simpler, and it also seems correct
since the LLVM Lang Ref defines simple true/false returns if the
operands are QNaN's. For SNaN's, even VCMPS throws an Invalid Operand
exception, so they won't be slipping through unnoticed.
Implementation-wise, this introduces a template so we can share the same
code that we use for handling integer comparisons, since the only
differences are in the details (exact opcodes to be used etc). Hopefully
this will be easy to extend to s64 G_FCMP.
llvm-svn: 307365
This fixes last testcase provided in PR28414.
In short issue is next: when we had X@@Version symbol in object A,
we did not resolve it to X early. Then when in another object B
we had reference to undefined X, symbol X from archive was fetched.
Since both archive and object A contains another symbol Z, duplicate
symbol definition was triggered as a result.
Correct behavior is to use X@@Version from object A instead and do not fetch
any symbols from archive.
Differential revision: https://reviews.llvm.org/D35059
llvm-svn: 307364
Some of our emitters were using the name of the Target to reference things that were created by others emitters using Namespace.
Apparently all targets have the same Target name as their instruction and register Namespace field?
Someone on IRC had a target that didn't do this and was getting build errors. This patch is a necessary, but maybe not sufficient fix.
llvm-svn: 307358
r283051 added some functions to cmath (in namespace std) that have the
same name as functions in math.h (in the global namespace). Clang's
limited support for `-fdelayed-template-parsing` chokes on this. Rename
the ones in `cmath` and their uses in `complex` and the test.
rdar://problem/32848355
llvm-svn: 307357
Based strictly on the name, this seems to have something to do
width edit & continue. The goal of this patch has nothing to do
with supporting edit and continue though. msvc link.exe writes
very basic information into this area even when *not* compiling
with support for E&C, and so the goal here is to bring lld-link
to parity. Since we cannot know what assumptions standard tools
make about the content of PDB files, we need to be as close as
possible.
This ECNames data structure is a standard PDB string hash table.
link.exe puts a single string into this hash table, which is the
full path to the PDB file on disk. It then references this string
from the module descriptor for the compiler generated `* Linker *`
module.
With this patch, lld-link will generate the exact same sequence of
bytes as MSVC link for this subsection for a given object file
input (as reported by `llvm-pdbutil bytes -ec`).
llvm-svn: 307356
- Instead of running with -O0, we enable the highest optimization level, but
then disable optimizations. This ensures that possibly important metadata
is still emitted.
- Update the code for attribute removal to work with latest LLVM
- Do not cut an arbitrary number of lines from the LL file. It is undocumented
why this was needed at the first place, and such a feature is likely to
break with trivial IR changes that may come in the future.
llvm-svn: 307355
When scavenging for a use in instruction MI, we will reload after
that instruction and hence cannot spill uses/defs of this instruction.
This fixes http://llvm.org/PR33687
llvm-svn: 307352
Contrary to the stepForward()/stepBackward() method accumulate() doesn't
have a direction as defs, uses and clobbers all have the same effect.
Also improve the documentation comment.
llvm-svn: 307351
This patch updates the ORC layers and utilities to return and propagate
llvm::Errors where appropriate. This is necessary to allow ORC to safely handle
error cases in cross-process and remote JITing.
llvm-svn: 307350
InferAddressSpaces does not check address space in collectFlatAddressExpressions,
which causes values with non flat address space put into Postorder and causes
assertion in cloneValueWithNewAddressSpace.
This patch fixes assertion in OpenCL 2.0 conformance test generic_address_space
subtest for amdgcn target.
Differential Revision: https://reviews.llvm.org/D34991
llvm-svn: 307349
Model weakly defined symbols as symbols that are both
exports and imported and marked as weak. Local references
to the symbols refer to the import but the linker can
resolve this to the weak export if not strong symbol
is found at link time.
Differential Revision: https://reviews.llvm.org/D35029
llvm-svn: 307348
Adds loop expansions for known-size and unknown-sized memcpy calls, allowing the
target to provide the operand types through TTI callbacks. The default values
for the TTI callbacks use int8 operand types and matches the existing behaviour
if they aren't overridden by the target.
Differential revision: https://reviews.llvm.org/D32536
llvm-svn: 307346
Revert "Copy arguments passed by value into explicit allocas for ASan."
Revert "[asan] Add end-to-end tests for overflows of byval arguments."
Build failure on lldb-x86_64-ubuntu-14.04-buildserver.
Test failure on clang-cmake-aarch64-42vma and sanitizer-x86_64-linux-android.
llvm-svn: 307345
This improves find_darwin_sdk_dir to cache the results of executing xcodebuild to find the SDK. Should significantly reduce the CMake re-configure time.
Differential Revision: https://reviews.llvm.org/D34736
llvm-svn: 307344
Included is one test for passing structs by value and one test for passing C++
objects by value.
Patch by Matt Morehouse.
Differential revision: https://reviews.llvm.org/D34827
llvm-svn: 307343
ASan determines the stack layout from alloca instructions. Since
arguments marked as "byval" do not have an explicit alloca instruction, ASan
does not produce red zones for them. This commit produces an explicit alloca
instruction and copies the byval argument into the allocated memory so that red
zones are produced.
Patch by Matt Morehouse.
Differential revision: https://reviews.llvm.org/D34789
llvm-svn: 307342
Added a new Enum to identify if the base pointer is exclusively null or
exlusively some constant or not exclusively any constant.
Converted the base pointer identification method from recursive to
iterative form.
llvm-svn: 307340
This is especially useful when lit is invoked indirectly by the build
system, and additional arguments can not be easily specified.
Differential Revision: https://reviews.llvm.org/D35091
llvm-svn: 307339
Using profile information to guide consthoisting is generally helpful for
performance, so the patch turns it on by default. No compile time or perf
regression were found using spec2000 and spec2006 on x86. Some significant
improvement (>20%) was seen on internal benchmarks.
Differential Revision: https://reviews.llvm.org/D35063
llvm-svn: 307338
Adds a CMake option DARWIN_PREFER_PUBLIC_SDK, off by default. When on, this prefers to use the public SDK, even when an internal one is present. With this, it's easy to emulate a build that the public buildbots are doing.
Differential Revision: https://reviews.llvm.org/D35071
llvm-svn: 307330
Summary: Use an argument adjuster to preserve behavior inadvertantly changed by D34304.
Reviewers: klimek
Differential Revision: https://reviews.llvm.org/D35095
llvm-svn: 307329
The patch is to adjust the strategy of frequency based consthoisting:
Previously when the candidate block has the same frequency with the existing
blocks containing a const, it will not hoist the const to the candidate block.
For that case, now we change the strategy to hoist the const if only existing
blocks have more than one block member. This is helpful for reducing code size.
Differential Revision: https://reviews.llvm.org/D35084
llvm-svn: 307328
The patch adds support of i128 params lowering. The changes are quite trivial to
support i128 as a "special case" of integer type. With this patch, we lower i128
params the same way as aggregates of size 16 bytes: .param .b8 _ [16].
Currently, NVPTX can't deal with the 128 bit integers:
* in some cases because of failed assertions like
ValVTs.size() == OutVals.size() && "Bad return value decomposition"
* in other cases emitting PTX with .i128 or .u128 types (which are not valid [1])
[1] http://docs.nvidia.com/cuda/parallel-thread-execution/index.html#fundamental-types
Differential Revision: https://reviews.llvm.org/D34555
Patch by: Denys Zariaiev (denys.zariaiev@gmail.com)
llvm-svn: 307326
Summary:
The capture() function was removed in r306625. This should fix PGO breakages
reported by Michael Zolotukhin.
Reviewers: mzolotukhin
Subscribers: sanjoy, llvm-commits
Differential Revision: https://reviews.llvm.org/D35088
llvm-svn: 307320
This fixes calls to external functions starting with a capital L,
fixing errors like this:
fatal error: error in backend: assembler label 'LocalFree' can not be undefined
Differential Revision: https://reviews.llvm.org/D35079
llvm-svn: 307317
Summary:
Most clang tools should ignore the -M
family of options because one wouldn't want them
to generate a new dependency (.d) file. However,
some tools may want this dependency file. This
patch creates a mechanism for them to do this.
This implementation just plumbs a boolean down
several layers of calls. Each of the modified calls
has several call sites, and so a single member
variable or new API entry point won't work.
An alternative would be to write a function to filter
the -M family of arguments out of CC1Args, and have
each caller call that function by hand before calling
newInvocation, Invocation::run, or buildAstFromCodeWithArgs.
This is a more complicated and error-prone solution.
Why burden all the callers to remember to use
this function?
But I could rewrite this patch to use that method if
that is deemed more appropriate.
Reviewers: klimek
Reviewed By: klimek
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D34304
llvm-svn: 307315
George Rimar