utils/update_test_checks.py was improved with:
http://reviews.llvm.org/rL265414
to include the first line of the function (expected to be
a comment line). This ensures that nothing bad has happened
before the first actual line of checked asm. It also matches
the existing behavior of the old script.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265416 91177308-0d34-0410-b5e6-96231b3b80d8
It was broken by reshuffling induced by r265397 'Don't delete empty preheaders in CodeGenPrepare if it would create a critical edge'.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265415 91177308-0d34-0410-b5e6-96231b3b80d8
We could make this an option if people don't like it.
But since part of the reason for using a script to generate
checks is to prevent lazy checking that lets bugs crawl
through, let's have the script check the first line too.
For asm tests, it ensures that nothing unexpected has
happened before the first line of asm. This matches the
existing behavior of update_llc_test_checks.py.
More discussion in PR22897:
https://llvm.org/bugs/show_bug.cgi?id=22897
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265414 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: LanaiSetflagAluCombiner could previously combine instructions across basic building blocks even when not legal. Make the LanaiSetflagAluCombiner more conservative to avoid this.
Reviewers: eliben
Subscribers: joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D18746
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265411 91177308-0d34-0410-b5e6-96231b3b80d8
Presently, CodeGenPrepare deletes all nearly empty (only phi and branch)
basic blocks. This pass can delete loop preheaders which frequently creates
critical edges. A preheader can be a convenient place to spill registers to
the stack. If the entrance to a loop body is a critical edge, then spills
may occur in the loop body rather than immediately before it. This patch
protects loop preheaders from deletion in CodeGenPrepare even if they are
nearly empty.
Since the patch alters the CFG, it affects a large number of test cases.
In most cases, the changes are merely cosmetic (basic blocks have different
names or instruction orders change slightly). I am somewhat concerned about
the test/CodeGen/Mips/brdelayslot.ll test case. If the loop preheader is not
deleted, then the MIPS backend does not take advantage of a branch delay
slot. Consequently, I would like some close review by a MIPS expert.
The patch also partially subsumes D16893 from George Burgess IV. George
correctly notes that CodeGenPrepare does not actually preserve the dominator
tree. I think the dominator tree was usually not valid when CodeGenPrepare
ran, but I am using LoopInfo to mark preheaders, so the dominator tree is
now always valid before CodeGenPrepare.
Author: Tom Jablin (tjablin)
Reviewers: hfinkel george.burgess.iv vkalintiris dsanders kbarton cycheng
http://reviews.llvm.org/D16984
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265397 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support for compact jumps similiar to the previous compact
branch support for MIPSR6. Unlike compact branches, compact jumps do not
have a forbidden slot.
As MipsInstrInfo::getEquivalentCompactForm can determine the correct
expansion for jumps and branches for both microMIPS and MIPSR6, remove the
unnecessary distinction in the delay slot filler.
Reviewers: vkalintiris
Subscribers: llvm-commits, dsanders
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265390 91177308-0d34-0410-b5e6-96231b3b80d8
Without setting the flag there is no way to determine if a symbol
points to an arm or to a thumb function as the LSB of the address
masked out in all getter function.
Note: Currently the thumb flag is only used for MachO files so
adding a test to this change is not possible. It will be used
by the upcoming fix for llvm-objdump for disassembling thumb
functions what is easily testable.
Differential revision: http://reviews.llvm.org/D17956
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265387 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
A character within a string literal is not escaped correctly.
In this case, there is no semantic change because the invalid character turn out to be NUL anyway.
note: "\0x12" is equivalent to {0, 'x', '1', '2'} and not { 12 }.
This issue was found by clang-tidy.
Reviewers: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D18747
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265376 91177308-0d34-0410-b5e6-96231b3b80d8
Refactor common code that queries the ModuleSummaryIndex for a value's
GlobalValueInfo struct into getGlobalValueInfo helper methods, which
will also be used by D18763.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265370 91177308-0d34-0410-b5e6-96231b3b80d8
Story time was nice a few years ago, but by now it's nice to state how things are, rather than explain the diff from ye olden atomic history. These were dark times.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265369 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
I encountered this issue when constant folding during inlining tried to
fold away a bitcast of a double to an x86_mmx, which is not an integral
type. The test case exposes the same issue with a smaller code snippet
during early CSE.
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D18528
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265367 91177308-0d34-0410-b5e6-96231b3b80d8
We were using array_pod_sort on an array of type 'Attribute', which
wraps a pointer to AttributeImpl. For the most part this didn't matter
because the printing code prints enum attributes in a defined order, but
integer attributes such as 'align' and 'dereferenceable' were not
ordered.
Furthermore, AttributeImpl::operator< was broken for integer attributes.
An integer attribute is a kind and an integer value, and both pieces
need to be compared.
By fixing the comparison operator, we can go back to std::sort, and
things look good now. This should fix clang arm-swiftcall.c test
failures on Windows.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265361 91177308-0d34-0410-b5e6-96231b3b80d8
There is no problem with the code today, but the fix will avoid a crash
in test/CodeGen/AMDGPU/subreg-coalescer-undef-use.ll once the
DetectDeadLanes pass is added.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265351 91177308-0d34-0410-b5e6-96231b3b80d8
We missed a handful of .mir tests that existed outside the
test/CodeGen/MIR directory.
Also fix the three powerpc .mir tests that nobody noticed were broken.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265350 91177308-0d34-0410-b5e6-96231b3b80d8
Remove a default parameter value being passed unnecessarily, which
also reduces the changes required when this parameter is changed in
D18763.
Document the remaining non-default bool value passed for another
parameter.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265348 91177308-0d34-0410-b5e6-96231b3b80d8
I noticed that this isn't covered by our existing tests and spent some
time trying to come up with an example it actually hits. I tried hand
rolling something based on the explanation in the comment, but couldn't
get anything that didn't abort tail duplication earlier for one reason
or another.
Then, I tried cranking tail-dup-size cranked up so this would fire
more and ran a bootstrap of clang and the nightly test suite - those
don't hit this either.
This reverts r132816 and replaces it with an assert.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265347 91177308-0d34-0410-b5e6-96231b3b80d8
This reduces unrelated changes in other patches (such as D18763) when
changes to this file are clang formatted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265346 91177308-0d34-0410-b5e6-96231b3b80d8
The original commit miscompiled things on 32-bit Windows, e.g. a Clang
boostrap. It turns out that mergeSPUpdates() was a bit too generous in
what it interpreted as a stack adjustment, causing the following code:
addl $12, %esp
leal -4(%ebp), %esp
To be "optimized" into simply:
addl $8, %esp
This commit tightens up mergeSPUpdates() and includes a new test
(test14 in movtopush.ll) for this situation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265345 91177308-0d34-0410-b5e6-96231b3b80d8
Adds some dllexport tests to verify that:
- Variables in bss are exported appropriately
- Non-dllexport symbols aliased to dllexport symbols are not exported
- Symbols declared as dllexport but are not defined are not exported
We plan to enable dllimport/dllexport support for the PS4, and these
additional tests are for points we noticed in our internal testing.
Patch by Warren Ristow!
Differential Revision: http://reviews.llvm.org/D18682
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265333 91177308-0d34-0410-b5e6-96231b3b80d8
That commit looks wonderful and awesome. Sadly, it greatly exacerbates
PR17409 and effectively regresses build time for a lot of (very large)
code when compiled with ASan or MSan.
We thought this could be fixed forward by landing D15302 which at last
fixes that PR, but some issues were discovered and it looks like that
got reverted, so reverting this as well temporarily. As soon as the fix
for PR17409 lands and sticks, we should re-land this patch as it won't
trigger more significant test cases hitting that bug.
Many thanks to Quentin and Wei here as they're doing all the awesome
hard work!!!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265331 91177308-0d34-0410-b5e6-96231b3b80d8
Direct callees' that are cast to other function prototypes,
show up in the Call/Invoke instructions as ConstantExpr's.
Currently llvm::CallSite's getCalledFunction() fails
to return the callees in such expressions as direct calls.
Value profiling should avoid instrumenting such cases. Mostly NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265330 91177308-0d34-0410-b5e6-96231b3b80d8
We can only perform a tail call to a callee that preserves all the
registers that the caller needs to preserve.
This situation happens with calling conventions like preserver_mostcc or
cxx_fast_tls. It was explicitely handled for fast_tls and failing for
preserve_most. This patch generalizes the check to any calling
convention.
Related to rdar://24207743
Differential Revision: http://reviews.llvm.org/D18680
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265329 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Useful for debugging since we lose this correlation after the permodule
summary/VST is read and until we later materialize source modules in the
function importer.
Reviewers: joker.eph
Subscribers: llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D18555
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265327 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
To aid in debugging, dump out the correlation between value names and
GUID for each source module when it is materialized. This will make it
easier to comprehend the earlier summary-based function importing debug
trace which only has access to and prints the GUIDs.
Reviewers: joker.eph
Subscribers: llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D18556
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265326 91177308-0d34-0410-b5e6-96231b3b80d8
A seg-fault occurs due to a reference of a null pointer, which is
the value returned by getConstantPart. This function returns
null if the constant part is not found. The code that calls this
function needs to check for the null return value.
Differential Revision: http://reviews.llvm.org/D18718
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265319 91177308-0d34-0410-b5e6-96231b3b80d8
