| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
| |
users over to the new one. No sense maintaining this "compatibility"
layer it seems.
llvm-svn: 171331
|
| |
|
|
|
|
|
|
| |
Implement the old API in terms of the new one. This simplifies the
implementation on Windows which can now re-use the self_process's once
initialization.
llvm-svn: 171330
|
| |
|
|
| |
llvm-svn: 171327
|
| |
|
|
|
|
|
| |
The new code is an improved copy of the code I deleted from Analysis/Loads.cpp.
One less compute-constant-gep-offset implementation. yay :)
llvm-svn: 171326
|
| |
|
|
|
|
| |
Hopefully with bugs corrected now.
llvm-svn: 171325
|
| |
|
|
|
|
| |
This reverts r171298. Breaks clang selfhost.
llvm-svn: 171318
|
| |
|
|
|
|
| |
Also add an assert to avoid confusion in the code where is known that C1 <= C2.
llvm-svn: 171310
|
| |
|
|
| |
llvm-svn: 171308
|
| |
|
|
|
|
| |
local implementation
llvm-svn: 171307
|
| |
|
|
| |
llvm-svn: 171306
|
| |
|
|
| |
llvm-svn: 171303
|
| |
|
|
| |
llvm-svn: 171298
|
| |
|
|
|
|
| |
AttrKind value.
llvm-svn: 171294
|
| |
|
|
|
|
|
|
| |
Fix a truly odd namespace qualifier that was flat out wrong in the
process. The fully qualified namespace would have been
llvm::sys::TimeValue, llvm::TimeValue makes no sense.
llvm-svn: 171292
|
| |
|
|
| |
llvm-svn: 171291
|
| |
|
|
| |
llvm-svn: 171290
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The coding style used here is not LLVM's style because this is modeled
after a Boost interface and thus done in the style of a candidate C++
standard library interface. I'll probably end up proposing it as
a standard C++ library if it proves to be reasonably portable and
useful.
This is just the most basic parts of the interface -- getting the
process ID out of it. However, it helps sketch out some of the boiler
plate such as the base class, derived class, shared code, and static
factory function. It also introduces a unittest so that I can
incrementally ensure this stuff works.
However, I've not even compiled this code for Windows yet. I'll try to
fix any Windows fallout from the bots, and if I can't fix it I'll revert
and get someone on Windows to help out. There isn't a lot more that is
mandatory, so soon I'll switch to just stubbing out the Windows side and
get Michael Spencer to help with implementation as he can test it
directly.
llvm-svn: 171289
|
| |
|
|
|
|
|
| |
promoting a store in a loop. This was noticed when working on PR14753,
but isn't directly related.
llvm-svn: 171281
|
| |
|
|
|
|
| |
PR14753
llvm-svn: 171279
|
| |
|
|
| |
llvm-svn: 171272
|
| |
|
|
|
|
| |
the getAttrSomewhere predicate. This prevents the uses of 'Attribute' as a collection of attributes.
llvm-svn: 171271
|
| |
|
|
|
|
|
| |
if C1 and C2 differ only with one bit.
Fixes PR14708.
llvm-svn: 171270
|
| |
|
|
|
|
|
|
| |
Fixes pr14751.
Patch by Kai; Thanks!
llvm-svn: 171261
|
| |
|
|
|
|
|
|
|
| |
GEP::accumulateConstantOffset().
The later API is nicer than the former, and is correct regarding wrap-around offsets (if anyone cares).
There are a few more places left with duplicated code, which I'll remove soon.
llvm-svn: 171259
|
| |
|
|
| |
llvm-svn: 171257
|
| |
|
|
|
|
| |
AttributeSet accessor method.
llvm-svn: 171256
|
| |
|
|
|
|
| |
methods instead.
llvm-svn: 171255
|
| |
|
|
|
|
|
|
|
| |
directly.
This is in preparation for removing the use of the 'Attribute' class as a
collection of attributes. That will shift to the AttributeSet class instead.
llvm-svn: 171253
|
| |
|
|
| |
llvm-svn: 171252
|
| |
|
|
|
|
|
|
|
| |
LCSSA PHIs may have undef values. The vectorizer updates values that are used by outside users such as PHIs.
The bug happened because undefs are not loop values. This patch handles these PHIs.
PR14725
llvm-svn: 171251
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* One that accepts a single Attribute::AttrKind.
* One that accepts an Attribute::AttrKind plus a list of values. This is for
attributes defined like this:
#1 = attributes { align = 4 }
* One that accepts a string, for target-specific attributes like this:
#2 = attributes { "cpu=cortex-a8" }
llvm-svn: 171249
|
| |
|
|
|
|
|
| |
stored here is of a certain kind. This is in preparation for when an Attribute
object represents a single attribute, instead of a bitmask of attributes.
llvm-svn: 171247
|
| |
|
|
|
|
|
|
|
| |
already uniquified.
Note: This will be expanded in the future to add more than just one pointer
value.
llvm-svn: 171245
|
| |
|
|
|
|
| |
method won't be sticking around.
llvm-svn: 171244
|
| |
|
|
|
|
| |
target-independent ISD nodes and use the existing patterns for those.
llvm-svn: 171237
|
| |
|
|
| |
llvm-svn: 171229
|
| |
|
|
|
|
| |
max/min instructions. Lower them to target specific nodes and use those patterns instead. This also allows them to be commuted if UnsafeFPMath is enabled.
llvm-svn: 171227
|
| |
|
|
| |
llvm-svn: 171226
|
| |
|
|
| |
llvm-svn: 171225
|
| |
|
|
| |
llvm-svn: 171221
|
| |
|
|
| |
llvm-svn: 171220
|
| |
|
|
|
|
|
| |
deleted this, but apparantly not. Charmingly, Clang didn't warn on it
but GCC did.
llvm-svn: 171197
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
propagating one of the values it simplified to a constant across
a myriad of instructions. Notably, ptrtoint instructions when we had
a constant pointer (say, 0) didn't propagate that, blocking a massive
number of down-stream optimizations.
This was uncovered when investigating why we fail to inline and delete
the boilerplate in:
void f() {
std::vector<int> v;
v.push_back(1);
}
It turns out most of the efforts I've made thus far to improve the
analysis weren't making it far purely because of this. After this is
fixed, the store-to-load forwarding patch enables LLVM to optimize the
above to an empty function. We still can't nuke a second push_back, but
for different reasons.
There is a very real chance this will cause somewhat noticable changes
in inlining behavior, so please let me know if you see regressions (or
improvements!) because of this patch.
llvm-svn: 171196
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
how to propagate constants through insert and extract value
instructions.
With the recent improvements to instsimplify, this allows inline cost
analysis to constant fold through intrinsic functions, including notably
the with.overflow intrinsic math routines which often show up inside of
STL abstractions. This is yet another piece in the puzzle of breaking
down the code for:
void f() {
std::vector<int> v;
v.push_back(1);
}
But it still isn't enough. There are a pile of bugs in inline cost still
blocking this.
llvm-svn: 171195
|
| |
|
|
|
|
|
|
| |
constant folding calls. Add the initial tests for this which show that
now instsimplify can simplify blindingly obvious code patterns expressed
with both intrinsics and library calls.
llvm-svn: 171194
|
| |
|
|
|
|
|
|
|
|
| |
are nice and decomposed so that we can simplify synthesized calls as
easily as actually call instructions. The internal utility still has the
same behavior, it just now operates on a more generic interface so that
I can extend the set of call simplifications that instsimplify knows
about.
llvm-svn: 171189
|
| |
|
|
| |
llvm-svn: 171183
|
| |
|
|
| |
llvm-svn: 171180
|
| |
|
|
| |
llvm-svn: 171179
|
| |
|
|
|
|
| |
optimizations. The old test cases still cover all of these lowering/optimizations. The single change that we have is that now anyext does not need to zero a register, because it does not use the exact code path as the zero_extend.
llvm-svn: 171178
|