| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
Bionic has a defined thread-local location for the stack protector
cookie. Emit a direct load instead of going through __stack_chk_guard.
llvm-svn: 265481
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17863
llvm-svn: 265480
|
| |
|
|
| |
llvm-svn: 265479
|
| |
|
|
| |
llvm-svn: 265475
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to this patch, CFLAA wouldn't tag arguments/globals properly if
it didn't find any "interesting" edges on them. This means that, if all
you do is store constants to a global or argument, we would never
actually treat it as a global/argument.
Test case:
define void @foo(i32* %A, i32* %B) #0 {
entry:
store i32 0, i32* %A, align 4
store i32 0, i32* %B, align 4
ret void
}
CFLAA would say that %A can't alias %B, because neither pointer was
used in an interesting way. This patch makes us note whether something
is an argument, global, ... regardless of how interesting CFLAA thinks
its uses are.
(For the record, using a value in an interesting way means loading
from it, using it in a GEP, ...)
llvm-svn: 265474
|
| |
|
|
| |
llvm-svn: 265473
|
| |
|
|
|
|
| |
r265465 wasn't good enough. I need to spell out all the moves.
llvm-svn: 265470
|
| |
|
|
|
|
|
|
| |
targeting jobs.
Now, addRegBankCoverage also adds the subreg-classes not just the
sub-classes of the given register class.
llvm-svn: 265469
|
| |
|
|
| |
llvm-svn: 265468
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Add a common parent class for ConstantArray, ConstantVector, and
ConstantStruct called ConstantAggregate. These are the aggregate
subclasses of Constant that take operands.
This is mainly a cleanup, adding common `isa` target and removing
duplicated code. However, it also simplifies caching which constants
point transitively at `GlobalValue` (a possible future direction).
llvm-svn: 265466
|
| |
|
|
|
|
|
| |
I can't remember if adding `= default` will make MSVC happy, or if I
have to spell this out. Let's try the cleaner version first.
llvm-svn: 265465
|
| |
|
|
| |
llvm-svn: 265464
|
| |
|
|
|
|
|
| |
Use the same assertion as ConstantArray. Vectors should have the right
number of elements.
llvm-svn: 265463
|
| |
|
|
|
|
|
|
| |
Change the default constructor to create invalid object.
The target will have to properly initialize the register banks before
using them.
llvm-svn: 265460
|
| |
|
|
|
|
|
|
|
|
| |
files; other minor fixes."
This reverts commit r265454 since it broke the build. E.g.:
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_build/22413/
llvm-svn: 265459
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit completely rewrites Mapper::mapMetadata (the implementation
of llvm::MapMetadata) using an iterative algorithm. The guts of the new
algorithm are in MDNodeMapper::map, the entry function in a new class.
Previously, Mapper::mapMetadata performed a recursive exploration of the
graph with eager "just in case there's a reason" malloc traffic.
The new algorithm has these benefits:
- New nodes and temporaries are not created eagerly.
- Uniquing cycles are not duplicated (see new unit test).
- No recursion.
Given a node to map, it does this:
1. Use a worklist to perform a post-order traversal of the transitively
referenced unmapped nodes.
2. Track which nodes will change operands, and which will have new
addresses in the mapped scheme. Propagate the changes through the
POT until fixed point, to pick up uniquing cycles that need to
change.
3. Map all the distinct nodes without touching their operands. If
RF_MoveDistinctMetadata, they get mapped to themselves; otherwise,
they get mapped to clones.
4. Map the uniqued nodes (bottom-up), lazily creating temporaries for
forward references as needed.
5. Remap the operands of the distinct nodes.
Mehdi helped me out by profiling this with -flto=thin. On his workload
(importing/etc. for opt.cpp), MapMetadata sped up by 15%, contributed
about 50% less to persistent memory, and made about 100x fewer calls to
malloc. The speedup is less than I'd hoped. The profile mainly blames
DenseMap lookups; perhaps there's a way to reduce them (e.g., by
disallowing remapping of MDString).
It would be nice to break the strange remaining recursion on the Value
side: MapValue => materializeInitFor => RemapInstruction => MapValue. I
think we could do this by having materializeInitFor return a worklist of
things to be remapped.
llvm-svn: 265456
|
| |
|
|
|
|
|
|
|
|
|
|
| |
other minor fixes.
Some Include What You Use suggestions were used too.
Use anonymous namespaces in source files.
Differential revision: http://reviews.llvm.org/D18778
llvm-svn: 265454
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We only generate LOCKed versions of add/sub when the result is unused.
It often happens that the result is used, but only by a comparison. We
can optimize those out by reusing EFLAGS, which lets us use the proper
instructions, instead of having to fallback to LXADD.
Instead of doing this as an MI peephole (as we do for the other
non-LOCKed (really, non-MR) forms), do it in ISel. It becomes quite
tricky later.
This also makes it eventually possible to stop expanding and/or/xor
if the only user is an icmp (also see D18141).
This uses the LOCK ISD opcodes added by r262244.
Differential Revision: http://reviews.llvm.org/D17633
llvm-svn: 265450
|
| |
|
|
| |
llvm-svn: 265449
|
| |
|
|
| |
llvm-svn: 265447
|
| |
|
|
| |
llvm-svn: 265445
|
| |
|
|
| |
llvm-svn: 265442
|
| |
|
|
|
|
|
| |
This pass is reponsible for assigning the generic virtual registers to register
banks.
llvm-svn: 265440
|
| |
|
|
| |
llvm-svn: 265434
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At IR level, the swifterror argument is an input argument with type
ErrorObject**. For targets that support swifterror, we want to optimize it
to behave as an inout value with type ErrorObject*; it will be passed in a
fixed physical register.
The main idea is to track the virtual registers for each swifterror value. We
define swifterror values as AllocaInsts with swifterror attribute or a function
argument with swifterror attribute.
In SelectionDAGISel.cpp, we set up swifterror values (SwiftErrorVals) before
handling the basic blocks.
When iterating over all basic blocks in RPO, before actually visiting the basic
block, we call mergeIncomingSwiftErrors to merge incoming swifterror values when
there are multiple predecessors or to simply propagate them. There, we create a
virtual register for each swifterror value in the entry block. For predecessors
that are not yet visited, we create virtual registers to hold the swifterror
values at the end of the predecessor. The assignments are saved in
SwiftErrorWorklist and will be materialized at the end of visiting the basic
block.
When visiting a load from a swifterror value, we copy from the current virtual
register assignment. When visiting a store to a swifterror value, we create a
virtual register to hold the swifterror value and update SwiftErrorMap to
track the current virtual register assignment.
Differential Revision: http://reviews.llvm.org/D18108
llvm-svn: 265433
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 265411
|
| |
|
|
|
|
|
|
|
| |
Removed the SDNode argument passed to the AI_smul and AI_smla multiclass
definitions as they are always mul.
Differential Revision: http://reviews.llvm.org/D18791
llvm-svn: 265409
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D18726
llvm-svn: 265408
|
| |
|
|
|
|
| |
NFC.
llvm-svn: 265407
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
critical edge
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
llvm-svn: 265397
|
| |
|
|
|
|
|
|
| |
Patch by Nicole Mazzuca <npmazzuca@gmail.com>.
Differential Revision: http://reviews.llvm.org/D18736
llvm-svn: 265394
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 265390
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: jingyue
Subscribers: jholewinski
Differential Revision: http://reviews.llvm.org/D18053
llvm-svn: 265389
|
| |
|
|
|
|
|
|
|
|
| |
this the default behavior.
Patch by Evgeny Stupachenko (evstupac@gmail.com).
Differential Revision: http://reviews.llvm.org/D18158
llvm-svn: 265388
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: The assert code is introduced by r265370.
Reviewers: bkramer
Subscribers: tejohnson
Differential Revision: http://reviews.llvm.org/D18786
llvm-svn: 265383
|
| |
|
|
|
|
|
|
|
|
|
| |
Second part extracted from http://reviews.llvm.org/D15525
Use GlobalIndirectSymbol in all cases when aliases and ifuncs have
something in common.
Differential Revision: http://reviews.llvm.org/D18754
llvm-svn: 265382
|
| |
|
|
|
|
|
|
| |
Refactor common code that queries the ModuleSummaryIndex for a value's
GlobalValueInfo struct into getGlobalValueInfo helper methods, which
will also be used by D18763.
llvm-svn: 265370
|
| |
|
|
| |
llvm-svn: 265368
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 265367
|
| |
|
|
|
|
| |
Extra semicolon.
llvm-svn: 265365
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 265361
|
| |
|
|
| |
llvm-svn: 265360
|
| |
|
|
| |
llvm-svn: 265356
|
| |
|
|
| |
llvm-svn: 265353
|
| |
|
|
|
|
|
|
|
|
|
| |
It seems this is reachable after all. It hit on 7zip-benchmark in lnt
on ppc64:
http://lab.llvm.org:8011/builders/clang-ppc64be-linux-lnt/builds/2317
This reverts r265347.
llvm-svn: 265352
|
| |
|
|
|
|
|
|
| |
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.
llvm-svn: 265351
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 265348
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 265347
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
eliminateCallFramePseudoInstr (PR27140)"
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.
llvm-svn: 265345
|
| |
|
|
|
|
|
|
|
|
| |
unroll factor, reducing it to maximum power-of-2 that satisfies threshold limit.
Commit for Evgeny Stupachenko (evstupac@gmail.com)
Differential Revision: http://reviews.llvm.org/D18290
llvm-svn: 265337
|