| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 194335
|
| |
|
|
|
|
|
|
| |
This commit cleans up some comments in ARMBuildAttrs.h.
Besides, this commit fixes an error related to AllowWMMXv1
and AllowWMMXv2 (although they are not used currently.)
llvm-svn: 194327
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
give the files a legacy prefix in the right directory. Use forwarding
headers in the old locations to paper over the name change for most
clients during the transitional period.
No functionality changed here! This is just clearing some space to
reduce renaming churn later on with a new system.
Even when the new stuff starts to go in, it is going to be hidden behind
a flag and off-by-default as it is still WIP and under development.
This patch is specifically designed so that very little out-of-tree code
has to change. I'm going to work as hard as I can to keep that the case.
Only direct forward declarations of the PassManager class are impacted
by this change.
llvm-svn: 194324
|
| |
|
|
| |
llvm-svn: 194311
|
| |
|
|
|
|
|
|
|
| |
formal arguments on the stack and stores created afterwards. We need this to
ensure tail call optimized function calls do not write over the argument area
of the stack before it is read out.
llvm-svn: 194309
|
| |
|
|
| |
llvm-svn: 194308
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch moves the jump address materialization inside the noop slide. This
enables patching of the materialization itself or its complete removal. This
patch also adds the ability to define scratch registers that can be used safely
by the code called from the patchpoint intrinsic. At least one scratch register
is required, because that one is used for the materialization of the jump
address. This patch depends on D2009.
Differential Revision: http://llvm-reviews.chandlerc.com/D2074
Reviewed by Andy
llvm-svn: 194306
|
| |
|
|
|
|
|
|
| |
This would cause internal symbols that are only referenced by global initializers to be removed.
This reverts commit 194219.
llvm-svn: 194304
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new graph structure replaces the node and edge linked lists with vectors.
Free lists (well, free vectors) are used for fast insertion/deletion.
The ultimate aim is to make PBQP graphs cheap to clone. The motivation is that
the PBQP solver destructively consumes input graphs while computing a solution,
forcing the graph to be fully reconstructed for each round of PBQP. This
imposes a high cost on large functions, which often require several rounds of
solving/spilling to find a final register allocation. If we can cheaply clone
the PBQP graph and incrementally update it between rounds then hopefully we can
reduce this cost. Further, once we begin pooling matrix/vector values (future
work), we can cache some PBQP solver metadata and share it between cloned
graphs, allowing the PBQP solver to re-use some of the computation done in
earlier rounds.
For now this is just a data structure update. The allocator and solver still
use the graph the same way as before, fully reconstructing it between each
round. I expect no material change from this update, although it may change
the iteration order of the nodes, causing ties in the solver to break in
different directions, and this could perturb the generated allocations
(hopefully in a completely benign way).
Thanks very much to Arnaud Allard de Grandmaison for encouraging me to get back
to work on this, and for a lot of discussion and many useful PBQP test cases.
llvm-svn: 194300
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The idea of the AnyReg Calling Convention is to provide the call arguments in
registers, but not to force them to be placed in a paticular order into a
specified set of registers. Instead it is up tp the register allocator to assign
any register as it sees fit. The same applies to the return value (if
applicable).
Differential Revision: http://llvm-reviews.chandlerc.com/D2009
Reviewed by Andy
llvm-svn: 194293
|
| |
|
|
|
|
| |
dead definitions by using live intervals, if available, to identify dead definitions and proceed accordingly.
llvm-svn: 194286
|
| |
|
|
|
|
|
|
|
|
| |
On darwin, when trying to create compact unwind info, a .cfi_cfa_def
directive would case an llvm_unreachable() to be hit. Back off when we
see this directive and generate the regular DWARF style eh_frame.
rdar://15406518
llvm-svn: 194285
|
| |
|
|
| |
llvm-svn: 194284
|
| |
|
|
|
|
| |
Thanks to Eric Christopher for the tips on the appropriate way to do this.
llvm-svn: 194282
|
| |
|
|
|
|
|
|
|
|
|
|
| |
LoopUnswitch's code simplification routine has logic to convert conditional
branches into unconditional branches, after unswitching makes the condition
constant, and then remove any blocks that renders dead. Unfortunately, this
code is dead, currently broken, and furthermore, has never been alive (at least
as far back at 2006).
No functionality change intended.
llvm-svn: 194277
|
| |
|
|
|
|
| |
Temporarily revert my previous commit until I understand why it breaks 3 target tests.
llvm-svn: 194272
|
| |
|
|
|
|
|
| |
isPhysRegUsed if the unwind information is required.
Indeed, the runtime may need a correct stack to be able to unwind the call.
llvm-svn: 194271
|
| |
|
|
|
|
| |
modifiers.
llvm-svn: 194270
|
| |
|
|
|
|
|
|
|
|
| |
Based on discussions with Lang Hames and Jakob Stoklund Olesen at the hacker's lab, and in the light of upcoming work on the PBQP register allocator, it was though that CalcSpillWeights does not need to be a pass. This change will enable to customize / tune the spill weight computation depending on the allocator.
Update the documentation style while there.
No functionnal change.
llvm-svn: 194269
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ARM prologues usually look like:
push {r7, lr}
sub sp, sp, #4
If code size is extremely important, this can be optimised to the single
instruction:
push {r6, r7, lr}
where we don't actually care about the contents of r6, but pushing it subtracts
4 from sp as a side effect.
This should implement such a conversion, predicated on the "minsize" function
attribute (-Oz) since I've yet to find any code it actually makes faster.
llvm-svn: 194264
|
| |
|
|
|
|
| |
ARMv8 (Thumb encodings)
llvm-svn: 194263
|
| |
|
|
|
|
| |
ARMv8 (ARM encodings)
llvm-svn: 194261
|
| |
|
|
| |
llvm-svn: 194259
|
| |
|
|
|
|
| |
The encoding was updated in MSA r1.07.
llvm-svn: 194255
|
| |
|
|
|
|
| |
as operands for coprocessor instructions, resulting in encodings that clash with FP/NEON instruction encodings
llvm-svn: 194253
|
| |
|
|
| |
llvm-svn: 194251
|
| |
|
|
|
|
|
| |
No additional test was needed, Other/constant-fold-gep.ll detects this
just fine.
llvm-svn: 194221
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Consider a GEP of:
i8* getelementptr ({ [2 x i8], i32, i8, [3 x i8] }* @main.c, i32 0, i32 0, i64 0)
If we proceeded to GEP the aforementioned object by 8, would form a GEP of:
i8* getelementptr ({ [2 x i8], i32, i8, [3 x i8] }* @main.c, i32 0, i32 0, i64 8)
Note that we would go through the first array member, causing an
out-of-bounds accesses. This is problematic because we might get fooled
if we are trying to evaluate loads using this GEP, for example, based
off of an object with a constant initializer where the array is zero.
This fixes PR17732.
Reviewers: nicholas, chandlerc, void
Reviewed By: void
CC: llvm-commits, echristo, void, aemerson
Differential Revision: http://llvm-reviews.chandlerc.com/D2093
llvm-svn: 194220
|
| |
|
|
|
|
|
|
|
|
| |
The BlockAddress doesn't have access to the correct basic blocks until the
functions have been cloned. This causes the BlockAddress to point to the old
values. Just wait until the functions have been cloned before copying the
initializers.
PR13163
llvm-svn: 194218
|
| |
|
|
| |
llvm-svn: 194205
|
| |
|
|
|
|
|
|
| |
of being converted and this path is not relevant to anything at this time
so I have just disabled it for a few days while I'm at the LLVM conference
and don't have time to complete it or properly fix it.
llvm-svn: 194201
|
| |
|
|
| |
llvm-svn: 194153
|
| |
|
|
|
|
|
| |
We can change this back when NEON support is complete and ready to become
enabled by default.
llvm-svn: 194152
|
| |
|
|
|
|
|
| |
I don't have a standalone testcase for this, but it should allow r193676
to be reapplied.
llvm-svn: 194148
|
| |
|
|
|
|
| |
clang-format are also included.
llvm-svn: 194145
|
| |
|
|
| |
llvm-svn: 194144
|
| |
|
|
|
|
| |
Original patch by Chris Wailes
llvm-svn: 194143
|
| |
|
|
|
|
|
| |
Presence of using namespace llvm depended on several #ifdef's, and
this broke the build on mswin32.
llvm-svn: 194142
|
| |
|
|
|
|
| |
Original patch by Chris Wailes
llvm-svn: 194139
|
| |
|
|
|
|
| |
Original patch by Chris Wailes
llvm-svn: 194137
|
| |
|
|
|
|
| |
Original patch by Chris Wailes
llvm-svn: 194135
|
| |
|
|
| |
llvm-svn: 194126
|
| |
|
|
| |
llvm-svn: 194123
|
| |
|
|
| |
llvm-svn: 194118
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Michele Scandale!
Rewrite of the functions used to compute the backedge taken count of a
loop on LT and GT comparisons.
I decided to split the handling of LT and GT cases becasue the trick
"a > b == -a < -b" in some cases prevents the trip count computation
due to the multiplication by -1 on the two operands of the
comparison. This issue comes from the conservative computation of
value range of SCEVs: taking the negative SCEV of an expression that
have a small positive range (e.g. [0,31]), we would have a SCEV with a
fullset as value range.
Indeed, in the new rewritten function I tried to better handle the
maximum backedge taken count computation when MAX/MIN expression are
used to handle the cases where no entry guard is found.
Some test have been modified in order to check the new value correctly
(I manually check them and reasoning on possible overflow the new
values seem correct).
I finally added a new test case related to the multiplication by -1
issue on GT comparisons.
llvm-svn: 194116
|
| |
|
|
|
|
| |
from MipsConstantIslands.
llvm-svn: 194108
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
MorphNodeTo is not safe to call during DAG building. It eagerly
deletes dependent DAG nodes which invalidates the NodeMap. We could
expose a safe interface for morphing nodes, but I don't think it's
worth it. Just create a new MachineNode and replaceAllUsesWith.
My understaning of the SD design has been that we want to support
early target opcode selection. That isn't very well supported, but
generally works. It seems reasonable to rely on this feature even if
it isn't widely used.
llvm-svn: 194102
|
| |
|
|
|
|
|
|
|
|
|
| |
we don't have such an operand.
Suprisingly enough, this is never actually accounted for in the
ARM version when determining offset ranges. In both places there is the
comment:
- // FIXME: Make use full range of soimm values.
(soimm = shift operand immediate).
llvm-svn: 194101
|
| |
|
|
|
|
| |
alignment will be handled differently than in ARM constant islands.
llvm-svn: 194096
|
| |
|
|
|
|
|
|
| |
Cortex-M0 supports these 32-bit instructions despite being Thumb1 only
(mostly). We knew about that but not that the aliases without the default "sy"
operand were also permitted.
llvm-svn: 194094
|