| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
various .cpp files. This macro is inherently non-modular, and it wasn't
even needed in this header file.
llvm-svn: 206775
|
| |
|
|
|
|
| |
instruction
llvm-svn: 206774
|
| |
|
|
|
|
|
|
|
| |
Tentative revert for
http://lab.llvm.org:8011/builders/llvm-mips-linux/builds/8305.
This reverts commit c2a58efff07294fca724f89500538f2ddbcd12ff.
llvm-svn: 206773
|
| |
|
|
| |
llvm-svn: 206772
|
| |
|
|
|
|
|
| |
Change `PositiveFloat` to `UnsignedFloat`, and fix some of the comments
to indicate that it's disappearing eventually.
llvm-svn: 206771
|
| |
|
|
| |
llvm-svn: 206769
|
| |
|
|
| |
llvm-svn: 206768
|
| |
|
|
| |
llvm-svn: 206767
|
| |
|
|
|
|
|
|
|
| |
This reverts commit r206707, reapplying r206704. The preceding commit
to CalcSpillWeights should have sorted out the failing buildbots.
<rdar://problem/14292693>
llvm-svn: 206766
|
| |
|
|
|
|
|
|
|
| |
This gross hack forces `hweight` into memory, preventing hidden
precision from making `1 > 1` occasionally equal `true`.
<rdar://problem/14292693>
llvm-svn: 206765
|
| |
|
|
|
|
|
|
| |
Use volatile store to protect the generated PTX from DCE.
Patch by Jingyue Wu.
llvm-svn: 206763
|
| |
|
|
| |
llvm-svn: 206759
|
| |
|
|
|
|
| |
It can be reverted a few days later, after X86Disassembler.d is updated not to contain "X86Disassembler.c".
llvm-svn: 206758
|
| |
|
|
| |
llvm-svn: 206756
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We normally don't drop functions from the C API's, but in this case I think we
can:
* The old implementation of getFileOffset was fairly broken
* The introduction of LLVMGetSymbolFileOffset was itself a C api breaking
change as it removed LLVMGetSymbolOffset.
* It is an incredibly specialized use case. The only reason MCJIT needs it is
because of its odd position of being a dynamic linker of .o files.
llvm-svn: 206750
|
| |
|
|
| |
llvm-svn: 206749
|
| |
|
|
| |
llvm-svn: 206747
|
| |
|
|
|
|
| |
memset/memcpy/memmove, replace the intrinsic with __asan_memset/etc. This makes the memset/etc handling more complete and consistent with what we do in msan. It may slowdown some cases (when the intrinsic was actually inlined) and speedup other cases (when it was not inlined)
llvm-svn: 206746
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LazyCallGraph analysis framework. Wire it up all the way through the opt
driver and add some very basic testing that we can build pass pipelines
including these components. Still a lot more to do in terms of testing
that all of this works, but the basic pieces are here.
There is a *lot* of boiler plate here. It's something I'm going to
actively look at reducing, but I don't have any immediate ideas that
don't end up making the code terribly complex in order to fold away the
boilerplate. Until I figure out something to minimize the boilerplate,
almost all of this is based on the code for the existing pass managers,
copied and heavily adjusted to suit the needs of the CGSCC pass
management layer.
The actual CG management still has a bunch of FIXMEs in it. Notably, we
don't do *any* updating of the CG as it is potentially invalidated.
I wanted to get this in place to motivate the new analysis, and add
update APIs to the analysis and the pass management layers in concert to
make sure that the *right* APIs are present.
llvm-svn: 206745
|
| |
|
|
|
|
|
|
|
|
| |
became empty. This would manifest later as an assert failure due to
a non-empty list map but an empty result map. This doesn't easily
manifest with just the module pass manager and the function pass
manager, but the next commit will add the CGSCC pass manager that hits
this assert immediately.
llvm-svn: 206744
|
| |
|
|
| |
llvm-svn: 206743
|
| |
|
|
| |
llvm-svn: 206741
|
| |
|
|
|
|
|
|
| |
break the API.
No functionality change.
llvm-svn: 206740
|
| |
|
|
|
|
| |
teach the opt driver to use it rather than a manual list.
llvm-svn: 206739
|
| |
|
|
|
|
|
|
|
|
| |
Generating BZHI in the variable mask case, i.e. (and X, (sub (shl 1, N), 1)),
was already supported, but we were missing the constant-mask case. This patch
fixes that.
<rdar://problem/15480077>
llvm-svn: 206738
|
| |
|
|
|
|
|
|
| |
file. This will make it easy to scale up the number of passes supported.
Currently, it just supports the function and module transformation
passes that were already supported in the opt tool explicitly.
llvm-svn: 206737
|
| |
|
|
|
|
|
|
| |
Original commit message:
Implement builtins for safe division: safe.sdiv.iN, safe.udiv.iN,
safe.srem.iN, safe.urem.iN (iN = i8, i61, i32, or i64).
llvm-svn: 206735
|
| |
|
|
| |
llvm-svn: 206734
|
| |
|
|
|
|
| |
safe.urem.iN (iN = i8, i16, i32, or i64).
llvm-svn: 206732
|
| |
|
|
| |
llvm-svn: 206730
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
It could even be made non-virtual if it weren't for bad compiler
warnings.
This demonstrates that ArgList objects aren't destroyed polymorphically
and possibly that they aren't even used polymorphically. If that's the
case, it might be possible to refactor the two ArgList types more
separately and simplify the Arg ownership model. *continues
experimenting*
llvm-svn: 206727
|
| |
|
|
| |
llvm-svn: 206726
|
| |
|
|
| |
llvm-svn: 206725
|
| |
|
|
|
|
|
|
| |
This might be able to be simplified further by using Arg as a value type
in a linked list (to maintain pointer validity), but here's something
simple to start with.
llvm-svn: 206724
|
| |
|
|
| |
llvm-svn: 206723
|
| |
|
|
| |
llvm-svn: 206722
|
| |
|
|
| |
llvm-svn: 206721
|
| |
|
|
|
|
| |
and ContextDecision in different source files (depending on #define magic).
llvm-svn: 206720
|
| |
|
|
|
|
| |
different source files.
llvm-svn: 206719
|
| |
|
|
|
|
| |
they need to...
llvm-svn: 206718
|
| |
|
|
|
|
|
|
|
|
| |
reason to expose a global symbol 'decodeInstruction' nor to pollute the global
scope with a bunch of external linkage entities (some of which conflict with
others elsewhere in LLVM).
This is just the initial transition to C++; more cleanups to follow.
llvm-svn: 206717
|
| |
|
|
|
|
| |
table entry for MIPS.
llvm-svn: 206716
|
| |
|
|
| |
llvm-svn: 206715
|
| |
|
|
|
|
|
|
|
| |
entirely clear whether this should be valid with modules enabled, but the fixed
code is cleaner regardless.
Also fix a TU-local type that accidentally had external linkage.
llvm-svn: 206714
|
| |
|
|
|
|
| |
Cleanup only.
llvm-svn: 206710
|
| |
|
|
|
|
| |
Spotted by Nick Lewycky in review, thanks!
llvm-svn: 206708
|
| |
|
|
|
|
| |
This reverts commit r206704, as expected.
llvm-svn: 206707
|
| |
|
|
|
|
| |
This reverts commit r206705, as planned.
llvm-svn: 206706
|
| |
|
|
|
|
|
|
|
|
|
| |
These tests fail after my BlockFrequencyInfo rewrite on two buildbots
[1][2]. I can't reproduce it locally, so I'm temporarily turning on
-debug-only=block-freq so I can find the problem.
[1]: http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/1860
[2]: http://llvm-amd64.freebsd.your.org/b/builders/clang-i386-freebsd/builds/18477
llvm-svn: 206705
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r206677, reapplying my BlockFrequencyInfo rewrite.
I've done a careful audit, added some asserts, and fixed a couple of
bugs (unfortunately, they were in unlikely code paths). There's a small
chance that this will appease the failing bots [1][2]. (If so, great!)
If not, I have a follow-up commit ready that will temporarily add
-debug-only=block-freq to the two failing tests, allowing me to compare
the code path between what the failing bots and what my machines (and
the rest of the bots) are doing. Once I've triggered those builds, I'll
revert both commits so the bots go green again.
[1]: http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/1816
[2]: http://llvm-amd64.freebsd.your.org/b/builders/clang-i386-freebsd/builds/18445
<rdar://problem/14292693>
llvm-svn: 206704
|