| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
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
|