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
Summary:
This adds the same checks that were added in r264593 to all
target-specific passes that run after register allocation.
Reviewers: qcolombet
Subscribers: jyknight, dsanders, llvm-commits
Differential Revision: http://reviews.llvm.org/D18525
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265313 91177308-0d34-0410-b5e6-96231b3b80d8
time issue. The patch is to solve PR17409 and its duplicates.
analyzeSiblingValues is a N x N complexity algorithm where N is
the number of siblings generated by reg splitting. Although it
causes siginificant compile time issue when N is large, it is also
important for performance since it removes redundent spills and
enables rematerialization.
To solve the compile time issue, the patch removes analyzeSiblingValues
and replaces it with lower cost alternatives containing two parts. The
first part creates a new spill hoisting method in postOptimization of
register allocation. It does spill hoisting at once after all the spills
are generated instead of inside every instance of selectOrSplit. The
second part queries the define expr of the original register for
rematerializaiton and keep it always available during register allocation
even if it is already dead. It deletes those dead instructions only in
postOptimization. With the two parts in the patch, it can remove
analyzeSiblingValues without sacrificing performance.
Differential Revision: http://reviews.llvm.org/D15302
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265309 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
At this point we should be able to enable IAS by default for O32 without
breaking check-all, or recursion.
Reviewers: vkalintiris
Subscribers: dsanders, llvm-commits
Differential Revision: http://reviews.llvm.org/D18439
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265302 91177308-0d34-0410-b5e6-96231b3b80d8
This adds MC support for fused compare + indirect branch instructions,
ie. CRB, CGRB, CLRB, CLGRB, CIB, CGIB, CLIB, CLGIB. They aren't actually
generated yet -- this is preparation for their use for conditional
returns in the next iteration of D17339.
Author: koriakin
Differential Revision: http://reviews.llvm.org/D18742
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265296 91177308-0d34-0410-b5e6-96231b3b80d8
A cross-thread sequentially consistent fence should be lowered into
z/Architecture's BCR serialization instruction, instead of causing a
fatal error in the back-end.
Author: bryanpkc
Differential Revision: http://reviews.llvm.org/D18644
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265292 91177308-0d34-0410-b5e6-96231b3b80d8
Enable the SystemZ back-end to lower FRAMEADDR and RETURNADDR, which
previously would cause the back-end to crash. Currently, only a
frame count of zero is supported.
Author: bryanpkc
Differential Revision: http://reviews.llvm.org/D18514
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265291 91177308-0d34-0410-b5e6-96231b3b80d8
Remove a few old FIXMEs from the original commit of the Metadata/Value
split in r223802. These are commented out assertions to the effect that
calls between mapValue and mapMetadata never return nullptr.
(The only behaviour change is that Mapper::mapSimpleMetadata memoizes
the nullptr return.)
When I originally rewrote the mapping code, I thought we could be
stricter in the new metadata hierarchy and never return nullptr when
RF_NullMapMissingGlobalValues was off. It's still not entirely clear to
me why these assertions failed (a few months ago, I had a theory that I
forgot to write down, but that's helping no one).
Understood or not, I no longer see how these commented-out assertions
would be useful. I'm relegating them to the annals of source control
before making significant changes to ValueMapper.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265282 91177308-0d34-0410-b5e6-96231b3b80d8
RAUW support on MDNode usually requires an extra allocation for
ReplaceableMetadataImpl. This is only strictly necessary if there are
tracking references to the MDNode. Make the construction of
ReplaceableMetadataImpl lazy, so that we don't get allocations if we
don't need them.
Since MDNode::isResolved now checks MDNode::isTemporary and
MDNode::NumUnresolved instead of whether a ReplaceableMetadataImpl is
allocated, the internal changes are intrusive (at various internal
checkpoints, isResolved now has a different answer).
However, there should be no real functionality change here; just
slightly lazier allocation behaviour. The external semantics should be
identical.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265279 91177308-0d34-0410-b5e6-96231b3b80d8
This adds an assertion to maintain the property from r265273. When
Mapper::mapSimpleMetadata calls Mapper::mapValue, it should not find its
way back to mapMetadataImpl. This guarantees that mapSimpleMetadata is
not involved in any recursion.
Since Mapper::mapValue calls out to arbitrary materializers, we need to
save a bit on the ValueMap to make this assertion effective.
There should be no functionality change here. This co-recursion should
already have been impossible.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265276 91177308-0d34-0410-b5e6-96231b3b80d8
The main change is to delay materializing GlobalValue initializers from
Mapper::mapValue until Mapper::~Mapper. This effectively removes all
recursion from mapSimplifiedMetadata, as promised in r265270.
mapSimplifiedMetadata calls mapValue for ConstantAsMetadata nodes to
find the mapped constant, and now it shouldn't be possible for mapValue
to indirectly re-invoke mapMetadata. I'll add an assertion to that
effect in a follow-up (separated so that the assertion can easily be
reverted independently, if it comes to that).
This a step toward a broader goal: converting Mapper::mapMetadataImpl
from a recursive to an iterative algorithm.
When a BlockAddress points at a BasicBlock inside an unmaterialized
function body, we need to delay it until the function body is
materialized in Mapper::~Mapper. This commit creates a temporary
BasicBlock and returns a new BlockAddress, then RAUWs the BasicBlock
once it is known. This situation should be extremely rare since a
BlockAddress is usually used from within the function it's referencing
(and BlockAddress itself is rare).
There should be no observable functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265273 91177308-0d34-0410-b5e6-96231b3b80d8
Split out a helper for mapping metadata without operands. This is any
metadata that is not an MDNode, and any MDNode where the answer is known
without looking at operands.
Through some weird twists, this function is co-recursive:
mapSimpleMetadata
=> MapValue
=> materializeInitFor
=> linkFunctionBody
=> RemapInstructions
=> MapMetadata
=> mapSimpleMetadata
I plan to break the recursion in a follow-up.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265270 91177308-0d34-0410-b5e6-96231b3b80d8
Add support for lowering with the MOVMSK instruction to extract vector element signbits to a GPR.
This is an early step towards more optimal handling of vector comparison results.
Differential Revision: http://reviews.llvm.org/D18741
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265266 91177308-0d34-0410-b5e6-96231b3b80d8
