| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
| |
subdirectories to traverse into.
- Originally I wanted to avoid this and just autoscan, but this has one key
flaw in that new subdirectories can not automatically trigger a rerun of the
llvm-build tool. This is particularly a pain when switching back and forth
between trees where one has added a subdirectory, as the dependencies will
tend to be wrong. This will also eliminates FIXME implicitly.
llvm-svn: 146436
|
| |
|
|
| |
llvm-svn: 146409
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
indicates whether the intrinsic has a defined result for a first
argument equal to zero. This will eventually allow these intrinsics to
accurately model the semantics of GCC's __builtin_ctz and __builtin_clz
and the X86 instructions (prior to AVX) which implement them.
This patch merely sets the stage by extending the signature of these
intrinsics and establishing auto-upgrade logic so that the old spelling
still works both in IR and in bitcode. The upgrade logic preserves the
existing (inefficient) semantics. This patch should not change any
behavior. CodeGen isn't updated because it can use the existing
semantics regardless of the flag's value.
Note that this will be followed by API updates to Clang and DragonEgg.
Reviewed by Nick Lewycky!
llvm-svn: 146357
|
| |
|
|
|
|
|
|
| |
don't do this now, but add a test case to prevent this from happening in the
future.
Additional test for rdar://9892684
llvm-svn: 145879
|
| |
|
|
| |
llvm-svn: 145801
|
| |
|
|
| |
llvm-svn: 145771
|
| |
|
|
|
|
|
|
|
| |
just to remove no blocks from the maps.
-15% on ARMDisassembler.cpp (Release build). It's not that great to add another
layer of caching to the caching-heavy LVI but I don't see a better way.
llvm-svn: 145770
|
| |
|
|
|
|
| |
rdar://10514247
llvm-svn: 145730
|
| |
|
|
|
|
| |
Add FIXMEs to places that are non-trivial to fix.
llvm-svn: 145661
|
| |
|
|
|
|
| |
for the suggestion, Eric.
llvm-svn: 145643
|
| |
|
|
|
|
| |
TLI isn't being passed to ensure we don't miss opportunities to fold calls.
llvm-svn: 145641
|
| |
|
|
|
|
| |
rdar://10500969
llvm-svn: 145639
|
| |
|
|
|
|
|
| |
where it appeared beneficial to pass.
More of rdar://10500969
llvm-svn: 145630
|
| |
|
|
|
|
|
| |
InstructionSimplify.cpp. Other fixups as needed.
Part of rdar://10500969
llvm-svn: 145559
|
| |
|
|
| |
llvm-svn: 145556
|
| |
|
|
|
|
| |
Fixes PR11431: SCEVExpander::expandAddRecExprLiterally(const llvm::SCEVAddRecExpr*): Assertion `(!isa<Instruction>(Result) || SE.DT->dominates(cast<Instruction>(Result), Builder.GetInsertPoint())) && "postinc expansion does not dominate use"' failed.
llvm-svn: 145482
|
| |
|
|
| |
llvm-svn: 145420
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
weak variable are compiled by different compilers, such as GCC and LLVM, while
LLVM may increase the alignment to the preferred alignment there is no reason to
think that GCC will use anything more than the ABI alignment. Since it is the
GCC version that might end up in the final program (as the linkage is weak), it
is wrong to increase the alignment of loads from the global up to the preferred
alignment as the alignment might only be the ABI alignment.
Increasing alignment up to the ABI alignment might be OK, but I'm not totally
convinced that it is. It seems better to just leave the alignment of weak
globals alone.
llvm-svn: 145413
|
| |
|
|
|
|
|
| |
This reverts r139450, fixes r139453, and adds much needed comments and a
unit test.
llvm-svn: 145367
|
| |
|
|
| |
llvm-svn: 145364
|
| |
|
|
|
|
| |
duplicating the logic for globals. Make llvm::ComputeMaskedBits handle GlobalVariables slightly more aggressively, to match what InferPtrAlignment knew how to do.
llvm-svn: 145304
|
| |
|
|
|
|
| |
SCEV should now be used for trip count analysis, not LoopInfo.
llvm-svn: 145262
|
| |
|
|
| |
llvm-svn: 145154
|
| |
|
|
|
|
| |
Fixes PR11426. Not sure if a test case with a "wrong" malloc would be useful.
llvm-svn: 145106
|
| |
|
|
|
|
|
|
| |
and positive: positive, because it could be directly computed to be positive;
negative, because the nsw flags means it is either negative or undefined (the
multiplication always overflowed).
llvm-svn: 145104
|
| |
|
|
| |
llvm-svn: 145047
|
| |
|
|
| |
llvm-svn: 145044
|
| |
|
|
| |
llvm-svn: 145014
|
| |
|
|
|
|
|
|
| |
Suggested in code review by Eli.
That code in InstCombine looks kinda suspicious.
llvm-svn: 145013
|
| |
|
|
|
|
| |
setFlags doesn't modify its arguments.
llvm-svn: 145007
|
| |
|
|
|
|
|
|
|
|
|
| |
The loop tree's inclusive block lists are painful and expensive to
update. (I have no idea why they're inclusive). The design was
supposed to handle this case but the implementation missed it and my
unit tests weren't thorough enough.
Fixes PR11335: loop unroll update.
llvm-svn: 144970
|
| |
|
|
|
|
| |
Fixes PR11375: Different results for 'clang++ huh.cpp'...
llvm-svn: 144746
|
| |
|
|
| |
llvm-svn: 144656
|
| |
|
|
| |
llvm-svn: 144648
|
| |
|
|
| |
llvm-svn: 144647
|
| |
|
|
|
|
|
|
|
|
| |
and stores capture) to permit the caller to see each capture point and decide
whether to continue looking.
Use this inside memdep to do an analysis that basicaa won't do. This lets us
solve another devirtualization case, fixing PR8908!
llvm-svn: 144580
|
| |
|
|
|
|
| |
loop. Fixes PR11361!
llvm-svn: 144454
|
| |
|
|
| |
llvm-svn: 144236
|
| |
|
|
|
|
| |
or not. Patch by Brendon Cahoon!
llvm-svn: 144173
|
| |
|
|
| |
llvm-svn: 144121
|
| |
|
|
| |
llvm-svn: 143719
|
| |
|
|
| |
llvm-svn: 143634
|
| |
|
|
|
|
|
|
|
|
|
|
| |
with the given predicate, it matches any condition and returns the
predicate - d'oh! Original commit message:
The expression icmp eq (select (icmp eq x, 0), 1, x), 0 folds to false.
Spotted by my super-optimizer in 186.crafty and 450.soplex. We really
need a proper infrastructure for handling generalizations of this kind
of thing (which occur a lot), however this case is so simple that I decided
to go ahead and implement it directly.
llvm-svn: 143318
|
| |
|
|
| |
llvm-svn: 143265
|
| |
|
|
|
|
|
|
|
| |
Spotted by my super-optimizer in 186.crafty and 450.soplex. We really
need a proper infrastructure for handling generalizations of this kind
of thing (which occur a lot), however this case is so simple that I decided
to go ahead and implement it directly.
llvm-svn: 143214
|
| |
|
|
|
|
| |
For completeness - not spotted in the wild.
llvm-svn: 143211
|
| |
|
|
|
|
| |
in 186.crafty.
llvm-svn: 143209
|
| |
|
|
|
|
|
|
|
|
|
| |
using BinaryOperator (which only works for instructions) when it should have
been a cast to OverflowingBinaryOperator (which also works for constants).
While there, correct a few other dubious looking uses of BinaryOperator.
Thanks to Chad Rosier for the testcase. Original commit message:
My super-optimizer noticed that we weren't folding this expression to
true: (x *nsw x) sgt 0, where x = (y | 1). This occurs in 464.h264ref.
llvm-svn: 143125
|
| |
|
|
|
|
| |
behind a compile failure on 483.xalancbmk.
llvm-svn: 143102
|
| |
|
|
|
|
| |
in 403.gcc and was spotted by my super-optimizer.
llvm-svn: 143054
|