| Commit message (Collapse) | Author | Age |
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146409 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
detected in the forward-CFG DFS. This prevents the reverse-CFG from
visiting blocks inside loops after blocks that dominate them in the
case where loops have multiple exits.
No testcase, because this fixes a bug which in practice only shows
up in a full optimizer run, due to the use-list order.
This fixes rdar://10422791 and others.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146408 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146407 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
This computes the offset of the layout sucessor block, considering its
alignment as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146401 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146400 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146397 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
| |
Downgrade the alignment of the initial constant island when constant
pool entries are moved elsewhere.
This is all gated by -arm-align-constant-islands.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146391 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146389 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
- Fixes PR11530.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146388 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146385 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146384 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146383 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
Also add an MCP member pointing to the machine constant pool.
No functional change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146382 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146380 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146379 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
Original commit message:
Support/FileSystem: Implement canonicalize.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146378 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146377 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
| |
Order constant pool entries by descending alignment in the initial
island to ensure packing and correct alignment. When the command line
flag is set, also align the basic block containing the constant pool
entries.
This is only a partial implementation of constant island alignment. More
to come.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146375 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146374 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
| |
CMake versions 2.8.4 and earlier were giving this error since r146323:
"string end index: -1 is out of range 0 - 6"
Passing -1 as the length of the desired substring was a new feature
added in CMake 2.8.5:
http://www.cmake.org/Bug/view.php?id=10740
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146372 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I followed three heuristics for deciding whether to set 'true' or
'false':
- Everything target independent got 'true' as that is the expected
common output of the GCC builtins.
- If the target arch only has one way of implementing this operation,
set the flag in the way that exercises the most of codegen. For most
architectures this is also the likely path from a GCC builtin, with
'true' being set. It will (eventually) require lowering away that
difference, and then lowering to the architecture's operation.
- Otherwise, set the flag differently dependending on which target
operation should be tested.
Let me know if anyone has any issue with this pattern or would like
specific tests of another form. This should allow the x86 codegen to
just iteratively improve as I teach the backend how to differentiate
between the two forms, and everything else should remain exactly the
same.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146370 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
intrinsic syntax.
Now that this is explicitly covered, I plan to upgrade the existing test
suite to use an explicit immediate. Note that I plan to specify 'true'
in most places rather than the auto-upgraded value as that is the far
more common value to end up here as that is the value coming from GCC's
builtins. The only place I'm likely to put a 'false' in is when testing
x86 which actually has different instructions for the two variants.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146369 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
a function to upgrade. Also, simplify the code a bit at the expense of
one line.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146368 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146364 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146363 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146362 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
| |
the behavior with the newly added flag for undefined results on a zero
input.
I'm terrible at documentation, so comments and suggestions welcome here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146361 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
argument of the cttz and ctlz intrinsics.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146360 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146357 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
Accidentally left out since r145214/r145217.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146356 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
The OptLevel is now redundant with the TargetMachine*.
And selectTarget() isn't really JIT-specific and could probably
get refactored into one of the lower level libraries.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146355 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
hanging around. Also remove a cast from inside getShuffleVPERM2X128Immediate and getShuffleVPERMILPImmediate since the only caller already had done the cast.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146344 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
for FSQRT, FSIN, FCOS, FPOWI, FPOW, FLOG, FLOG2, FLOG10, FEXP, FEXP2). Third attempt: simplified checks in test for armv7-apple-darwin11.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146341 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146340 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
need optional tools dir. MSVC and mingw may need one.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146339 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
of r146334!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146338 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146335 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
the only parts of TM that depends on CodeGen headers with it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146334 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
such as what VCS information is attached.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146333 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146332 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
Disable while I investigate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146331 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
| |
Fixed bug 9905: Failure in code selection for llvm intrinsics sqrt/exp (fix for
FSQRT, FSIN, FCOS, FPOWI, FPOW, FLOG, FLOG2, FLOG10, FEXP, FEXP2). Second
attempt.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146328 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146327 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
commit-ish. Funny thing, they have a command designed for this. ;]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146325 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
revision and git commit data extracted. This will be used in the Clang
CMake build to avoid trying to re-detect the information.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146324 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in CMake a bit more handy. Previously we would get such charming
versions as the following for revision NNNN and commit-ish XXXXX:
3.1svnsvn-rNNNN
3.1svngit-svn-rNNNN
3.1svngit-svn-XXXXX
The mechanism selecting betwene the latter two was particularly odd, and
didn't work with all of the ways git-svn repos are set up apparently. It
also misses an important point -- both the revision *and* the git commit
might be relevant when working on a local branch some distance from
mainline. The new logic does several things:
1) It strips the redundant initial 'svn'.
2) It always looks for a git-svn revision number base, and when found
includes it in the version.
3) If the git commit-ish for the current HEAD is not exactly that
revision number, it is also included.
The resulting strings should roughly be:
3.1svn-rNNNN
3.1git-svn-rNNNN
3.1git-svn-rNNNN-XXXXX
Suggestions on formatting etc always welcome. =] I've only looked at the
LLVM version string here, not Clang's (yet).
Note that the commit-ish reported is *not* terribly accurate. It updates
when 'cmake' is run, not when the binary is built. Still, it may be
better than nothing, especially if people have fairly long-lived git
repos and branches. This is not a new limitation, just didn't want
anyone to be surprised.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146323 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
for FSQRT, FSIN, FCOS, FPOWI, FPOW, FLOG, FLOG2, FLOG10, FEXP, FEXP2). Second attempt.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146322 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
use the register scavenger because the scavenger can only scavenge one register and frame-index elimination may have already grabbed it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146318 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146316 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The split point is picked such that the newly created water has the same
alignment as the function. This makes the island suitable for constant
pool entries with potentially higher alignment.
This also fixes an issue where the basic block was split one instruction
too late, causing nonconvergence of the algorithm.
<rdar://problem/10550705>
There is still an issue with correctly packing differently aligned
entries in the island.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146314 91177308-0d34-0410-b5e6-96231b3b80d8
|