| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
| |
This patch removes most of the trivial cases of weak vtables by pinning them to
a single object file.
Differential Revision: http://llvm-reviews.chandlerc.com/D2068
Reviewed by Andy
llvm-svn: 194865
|
|
|
|
|
|
|
|
| |
Working on a better solution to this.
This reverts commit 7d4e9934e7ca83094c5cf41346966c8350179ff2.
llvm-svn: 190990
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This puts all the global PassManager debugging flags, like
-print-after-all and -time-passes, behind a managed static. This
eliminates their static initializers and, more importantly, exit-time
destructors.
The only behavioral change I anticipate is that tools need to
initialize the PassManager before parsing the command line in order to
export these options, which makes sense. Tools that already initialize
the standard passes (opt/llc) don't need to do anything new.
llvm-svn: 190974
|
|
|
|
|
|
|
| |
This centralizes the handling of O_BINARY and opens the way for hiding more
differences (like how open behaves with directories).
llvm-svn: 186447
|
|
|
|
|
|
|
|
|
|
|
| |
that work on the LLVMBuild based dependency specification didn't
actually work, we just now maintain dependencies in *3* places instead
of 2. Yay.
There may still be some missing dependencies, I'm still sifting through
the bots and my builds, but this is a step in the right direction.
llvm-svn: 177988
|
|
|
|
| |
llvm-svn: 176123
|
|
|
|
| |
llvm-svn: 173141
|
|
|
|
|
|
| |
implementation lives already.
llvm-svn: 171746
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.
There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.
The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.
I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).
I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.
llvm-svn: 171366
|
|
|
|
|
|
|
|
| |
Again, tools are trickier to pick the main module header for than
library source files. I've started to follow the pattern of using
LLVMContext.h when it is included as a stub for program source files.
llvm-svn: 169252
|
|
|
|
|
|
|
| |
start up and clean up module passes, now that ASAN and TSAN are fixed the
tests pass
llvm-svn: 168905
|
|
|
|
|
|
|
|
| |
doInitialization and doFinalization per module detangled from runOn?? calls, still has temporary code not to break ASAN to be removed when that pass conforms to the proposed model".
It appears to have broken at least one buildbot.
llvm-svn: 168654
|
|
|
|
|
|
|
|
| |
doFinalization per module detangled from runOn?? calls, still has temporary code not to break ASAN to be removed when that pass conforms to the proposed model
Patch by Pedro Artigas, with feedback from by Chandler Carruth.
llvm-svn: 168635
|
|
|
|
|
|
|
|
| |
them to be re-initialized and reused on multiple Module's.
Patch by Pedro Artigas.
llvm-svn: 168008
|
|
|
|
|
|
|
|
| |
This was making it hard to scan my builds for new warnings. The
warning still fires with ToT clang. But if my workaround is unnecessary
for whatever reason, feel free to revert.
llvm-svn: 164201
|
|
|
|
|
|
| |
the order in which loops are generated.
llvm-svn: 158908
|
|
|
|
|
|
|
|
| |
conversion between the two.
Patch by nobled <nobled@dreamwidth.org>
llvm-svn: 154772
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ConstantFP::get(Type*, double) is unreliably host-specific:
it can't handle a type like PPC128 on an x86 host. It even
has a comment to that effect: "This should only be used for
simple constant values like 2.0/1.0 etc, that are
known-valid both as host double and as the target format."
Instead, use APFloat. While we're at it, randomize the floating
point value more thoroughly; it was previously limited
to the range 0 to 2**19 - 1.
PR12451.
llvm-svn: 154446
|
|
|
|
|
|
|
|
|
|
|
|
| |
LangRef.html says:
"There are no arrays, vectors or constants of this type."
This was hitting assertions when passing the -generate-x86-mmx
option.
PR12452.
llvm-svn: 154445
|
|
|
|
| |
llvm-svn: 151680
|
|
|
|
|
|
| |
(half, ppcf128, mmx, etc.)
llvm-svn: 151596
|
|
|
|
|
|
| |
Patch by Joey Gouly.
llvm-svn: 151489
|
|
|
|
| |
llvm-svn: 151488
|
|
|
|
| |
llvm-svn: 151487
|
|
|
|
|
|
| |
Thanks zygoloid.
llvm-svn: 151481
|
|
|
|
| |
llvm-svn: 151480
|
|
llvm-svn: 151479
|