| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 262989
|
| |
|
|
| |
llvm-svn: 262988
|
| |
|
|
|
|
|
|
| |
It is a transitive dependency, so static build are OK but not build
with individual DSO for each LLVM library.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 262987
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The next step is to actually turn CommandAlias into a full-blown CommandObject citizen.
This is tricky given the current architecture of the CommandInterpreter but I think I have found a reasonable path forward.
The current plan is to make class CommandAlias : public CommandObject, and have all the several GetCommand calls not actually traverse through the alias to the underlying command object
The only times that an alias will be traversed are:
a) execution; when time comes to run an alias, I will just grab the underlying command and options, and make the interpreter execute that according to its current algorithm
b) subcommand traversal; if one has an alias to a multiword command, grabbing a subcommand will see through to the subcommand
Other operations, e.g. command listing, command names, command helps, ..., will all use the alias directly. This will, in turn, lead to the removal of the separate alias dictionary, and just mix user commands and aliases in one map
llvm-svn: 262986
|
| |
|
|
|
|
|
|
| |
ObjCProtocolRef declarations, and fix related crash.
rdar://25035376
llvm-svn: 262985
|
| |
|
|
| |
llvm-svn: 262984
|
| |
|
|
|
|
| |
Thanks to Rui for spotting this.
llvm-svn: 262983
|
| |
|
|
|
|
|
|
| |
This implements a very simple conservative transformation that doesn't
require more than linear code size growth. There's room for much more
optimization in this space.
llvm-svn: 262982
|
| |
|
|
|
| |
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 262981
|
| |
|
|
| |
llvm-svn: 262980
|
| |
|
|
|
|
|
|
|
| |
Building on the previous change, this generalizes
ScalarEvolution::getRangeViaFactoring to work with
{Ext(C?A:B)+k0,+,Ext(C?A:B)+k1} where Ext can be a zero extend, sign
extend or truncate operation, and k0 and k1 are constants.
llvm-svn: 262979
|
| |
|
|
|
|
|
|
| |
This change generalizes ScalarEvolution::getRangeViaFactoring to work
with {Ext(C?A:B),+,Ext(C?A:B)} where Ext can be a zero extend, sign
extend or truncate operation.
llvm-svn: 262978
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is intended to provide a parallel (threaded) ThinLTO scheme
for linker plugin use through the libLTO C API.
The intent of this patch is to provide a first implementation as a
proof-of-concept and allows linker to start supporting ThinLTO by
definiing the libLTO C API. Some part of the libLTO API are left
unimplemented yet. Following patches will add support for these.
The current implementation can link all clang/llvm binaries.
Differential Revision: http://reviews.llvm.org/D17066
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 262977
|
| |
|
|
|
|
|
| |
reference (NFC)
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 262976
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Reviewers: rafael
Subscribers: Bigcheese, llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D17974
llvm-svn: 262975
|
| |
|
|
|
|
| |
It will come back when we add support for inline asm in .bc files.
llvm-svn: 262972
|
| |
|
|
| |
llvm-svn: 262971
|
| |
|
|
|
|
|
|
| |
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D17972
llvm-svn: 262970
|
| |
|
|
| |
llvm-svn: 262969
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This causes the issue in PR26872 to go away now that we aren't creating
symbols for the string literals, but that may just be concealing a
deeper problem, so best to keep that PR open.
Reviewers: rafael
Subscribers: Bigcheese, llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D17971
llvm-svn: 262968
|
| |
|
|
|
|
|
| |
not obvious how to access-check these, so pick a conservative rule until we get
feedback from CWG.
llvm-svn: 262966
|
| |
|
|
| |
llvm-svn: 262965
|
| |
|
|
| |
llvm-svn: 262964
|
| |
|
|
|
|
| |
classes; these are initialized as if they were data members.
llvm-svn: 262963
|
| |
|
|
|
|
|
| |
This patch adds the -lines command line option which will dump
source/line information for each compiland and source file.
llvm-svn: 262962
|
| |
|
|
| |
llvm-svn: 262961
|
| |
|
|
|
|
| |
triggers parsing diagnostics that may also be picked up during semantic analysis.
llvm-svn: 262960
|
| |
|
|
| |
llvm-svn: 262959
|
| |
|
|
|
|
| |
Store std::unique_ptr<CommandAlias> instead of instances
llvm-svn: 262958
|
| |
|
|
|
|
|
| |
It doesn't look like anything is depending on using local dynamic tls
relocations with preemptable symbols.
llvm-svn: 262957
|
| |
|
|
| |
llvm-svn: 262956
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It was a badly specified hack for when a tls relocation should be
propagated to the dynamic relocation table.
This replaces it with a not as bad hack of saying that a local dynamic
tls relocation is never preempted.
I will try to remove even that second hack in the next patch.
llvm-svn: 262955
|
| |
|
|
|
|
|
|
| |
When the symbol can be preempted the error is not entirely accurate.
This just makes upcoming patches more readable.
llvm-svn: 262954
|
| |
|
|
| |
llvm-svn: 262953
|
| |
|
|
| |
llvm-svn: 262952
|
| |
|
|
|
|
| |
Apparently this makes my email address easier to find.
llvm-svn: 262951
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
self.expect() had two problems:
- If there was a substrs argument, then it overwrote the variable containing
the command to run with the last substr. That meant nonsense command text in
testsuite errors.
- The actual output is not printed, which makes fixing testsuite failures a bit
annoying (you end up having to use the -tv arguments to dotest).
This fixes both of these issues. We could do even better, pretty-printing the
criteria for "correct" output, but this at least makes dealing with errors a bit
better.
llvm-svn: 262950
|
| |
|
|
|
|
|
|
| |
Add a missing include. This is important in the case HandleLLVMOptions is
included prior to the missing CheckCXXSourceCompiles or CheckCXXCompilerFlag
which includes CheckCXXSourceCompiles.
llvm-svn: 262949
|
| |
|
|
|
|
| |
This adds llvm_add_implicit_projects which takes a project name and is wrapped by add_llvm_implicit_projects.
llvm-svn: 262948
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The System-V x86_64 ABI requires floating point values to be passed
in 128-but SSE vector registers (xmm0, ...). When printing such a
variable this currently yields an <invalid load address>.
This patch makes LLDB's DWARF expression evaluator accept 128-bit
registers as scalars. It also relaxes the check that the size of the
result of the DWARF expression be equal to the size of the variable to a
greater-than. DWARF defers to the ABI how smaller values are being placed
in a larger register.
Implementation note: I found the code in Value::SetContext() that changes
the m_value_type after the fact to be questionable. I added a sanity check
that the Value's memory buffer has indeed been written to (this is
necessary, because we may have a scalar value in a vector register), but
really I feel like this is the wrong place to be setting it.
Reviewed by Greg Clayton.
http://reviews.llvm.org/D17897
rdar://problem/24944340
llvm-svn: 262947
|
| |
|
|
| |
llvm-svn: 262944
|
| |
|
|
|
|
|
|
| |
The fix consisting in using the library call for atomic compare and swap when
the instruction is not safe to use may be incorrect. Indeed the library call may
not exist on all platform. In other words, we need a better fix!
llvm-svn: 262943
|
| |
|
|
|
|
|
| |
Test to be committed in follow up commit, per discussion in D17097.
http://reviews.llvm.org/D17097
llvm-svn: 262942
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was causing errors like
/lib/libc.so.6 is incompatible with elf_x86_64
when linking on Fedora.
Every system has different default paths. It seems better to just trust
the driver to pass the correct -L options.
This reverts commit 262910.
llvm-svn: 262941
|
| |
|
|
| |
llvm-svn: 262940
|
| |
|
|
|
|
|
| |
This was inadvertently omitted from r262774, which added the mutation
interface.
llvm-svn: 262939
|
| |
|
|
|
|
| |
2015 Win64 Debug due to the section limit.
llvm-svn: 262938
|
| |
|
|
| |
llvm-svn: 262937
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: t.p.northover, grosbach, resistor
Subscribers: aemerson, rengolin, llvm-commits
Differential Revision: http://reviews.llvm.org/D17636
llvm-svn: 262936
|
| |
|
|
|
|
|
|
| |
ZERO_EXTEND_VECTOR_INREG"
This caused PR26870.
llvm-svn: 262935
|