| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
This is a mechanical change of comments in switches like fallthrough,
fall-through, or fall-thru to use the LLVM_FALLTHROUGH macro instead.
llvm-svn: 278902
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a quick work around, because in some cases, e.g. caller's stack
size > callee's stack size, we are still able to apply sibling call
optimization even callee has any byval arg.
This patch fix: https://llvm.org/bugs/show_bug.cgi?id=28328
Reviewers: hfinkel kbarton nemanjai amehsan
Subscribers: hans, tjablin
https://reviews.llvm.org/D23441
llvm-svn: 278900
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
minimal and boring form than the old pass manager's version.
This pass does the very minimal amount of work necessary to inline
functions declared as always-inline. It doesn't support a wide array of
things that the legacy pass manager did support, but is alse ... about
20 lines of code. So it has that going for it. Notably things this
doesn't support:
- Array alloca merging
- To support the above, bottom-up inlining with careful history
tracking and call graph updates
- DCE of the functions that become dead after this inlining.
- Inlining through call instructions with the always_inline attribute.
Instead, it focuses on inlining functions with that attribute.
The first I've omitted because I'm hoping to just turn it off for the
primary pass manager. If that doesn't pan out, I can add it here but it
will be reasonably expensive to do so.
The second should really be handled by running global-dce after the
inliner. I don't want to re-implement the non-trivial logic necessary to
do comdat-correct DCE of functions. This means the -O0 pipeline will
have to be at least 'always-inline,global-dce', but that seems
reasonable to me. If others are seriously worried about this I'd like to
hear about it and understand why. Again, this is all solveable by
factoring that logic into a utility and calling it here, but I'd like to
wait to do that until there is a clear reason why the existing
pass-based factoring won't work.
The final point is a serious one. I can fairly easily add support for
this, but it seems both costly and a confusing construct for the use
case of the always inliner running at -O0. This attribute can of course
still impact the normal inliner easily (although I find that
a questionable re-use of the same attribute). I've started a discussion
to sort out what semantics we want here and based on that can figure out
if it makes sense ta have this complexity at O0 or not.
One other advantage of this design is that it should be quite a bit
faster due to checking for whether the function is a viable candidate
for inlining exactly once per function instead of doing it for each call
site.
Anyways, hopefully a reasonable starting point for this pass.
Differential Revision: https://reviews.llvm.org/D23299
llvm-svn: 278896
|
| |
|
|
| |
llvm-svn: 278888
|
| |
|
|
|
|
|
|
| |
llvm::tryFoldSPUpdateIntoPushPop assumes its arguments are valid
MachineInstrs. Update ARMFrameLowering::emitPrologue to respect that;
when LastPush==end(), it can't possibly be a push instruction anyway.
llvm-svn: 278880
|
| |
|
|
| |
llvm-svn: 278878
|
| |
|
|
|
|
|
| |
The end() iterator isn't a safe thing to dereference. Pass the DebugLoc
into EmitFetchClause and EmitALUClause to avoid it.
llvm-svn: 278873
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D23556
llvm-svn: 278863
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
for code size savings, for 64-bit constants.
This patch handles 64-bit constants which can be encoded as 32-bit immediates.
It extends the functionality added by https://reviews.llvm.org/D11363 for 32-bit constants to 64-bit constants.
Patch by Sunita Marathe!
Differential Revision: https://reviews.llvm.org/D23391
llvm-svn: 278857
|
| |
|
|
|
|
| |
Refine the model for the FP division unit.
llvm-svn: 278846
|
| |
|
|
|
|
| |
Refine the model for the integer division unit.
llvm-svn: 278845
|
| |
|
|
|
|
|
|
|
|
|
| |
The structs ImmOp and RegOp are in AArch64AsmParser.cpp (inside
anonymous namespace).
This diff changes the order of fields and removes the excessive padding
(8 bytes).
Patch by Alexander Shaposhnikov
llvm-svn: 278844
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
ALIGNA PS_aligna
ALLOCA PS_alloca
TFR_FI PS_fi
TFR_FIA PS_fia
TFR_PdFalse PS_false
TFR_PdTrue PS_true
VMULW PS_vmulw
VMULW_ACC PS_vmulw_acc
llvm-svn: 278832
|
| |
|
|
|
|
|
|
|
|
|
| |
Check both operands for use of the $zero register which cannot be used with
a compact branch instruction.
Reviewers: dsanders, vkalintris
Differential Review: https://reviews.llvm.org/D23547
llvm-svn: 278824
|
| |
|
|
| |
llvm-svn: 278823
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- Remove unused instructions: LDriq_pred_vec_V6, STriq_pred_vec_V6, and
the 128B counterparts.
- Rename:
LDriq_pred_V6 PS_vloadrq_ai
LDriq_pred_V6_128B PS_vloadrq_ai_128B
STriq_pred_V6 PS_vstorerq_ai
STriq_pred_V6_128B PS_vstorerq_ai_128B
llvm-svn: 278813
|
| |
|
|
| |
llvm-svn: 278810
|
| |
|
|
|
|
|
| |
We're going to need it for G_MUL, and, if other targets end up using
something similar, we can easily put it in the generic selector.
llvm-svn: 278808
|
| |
|
|
|
|
| |
For now, no support for immediates.
llvm-svn: 278804
|
| |
|
|
|
|
| |
And mark it as legal.
llvm-svn: 278802
|
| |
|
|
|
|
|
|
| |
Following the discussion on D22038, this refactors a PowerPC specific setcc -> srl(ctlz) transformation so it can be used by other targets.
Differential Revision: https://reviews.llvm.org/D23445
llvm-svn: 278799
|
| |
|
|
|
|
|
|
| |
byte rotations
The combine was only matching v2i64 as it assumed lowering to MOVQ - but we have v2f64 patterns that match in a similar fashion
llvm-svn: 278794
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fix for the upper bound check that was causing a build failure.
Reviewers: olista01, rengolin, t.p.northover
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D23501
llvm-svn: 278789
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The assembler currently does not check the branch target for CBZ/CBNZ
instructions, which only permit branching forwards with a positive offset. This
adds validation for the branch target to ensure negative PC-relative offsets are
not encoded into the instruction, whether specified as a literal or as an
assembler symbol.
Reviewers: rengolin, t.p.northover
Subscribers: llvm-commits, rengolin
Differential Revision: https://reviews.llvm.org/D23312
llvm-svn: 278788
|
| |
|
|
| |
llvm-svn: 278787
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D23450
llvm-svn: 278784
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D21958
llvm-svn: 278782
|
| |
|
|
|
|
|
|
|
|
| |
Recall that MSVC always gives enums the type 'int', nothing else. MSVC
2015 does not appear to have this problem anymore.
Clang-cl -Wmicrosoft-enum-value flags this, FWIW, so now I have a true
positive for my warning. :)
llvm-svn: 278762
|
| |
|
|
|
|
|
|
|
| |
Use patterns instead of multiple instructions
Add buffer id to asm string
https://reviews.llvm.org/D22650
llvm-svn: 278749
|
| |
|
|
|
|
|
|
|
|
|
| |
This currently breaks the greendragon clang-stage1-configure-RA/ and
brotli. It is probably just uncovering a pre-existing problem. Reverting
temporarily to get the buildbots green again. A reduced testcase will
follow shortly.
This reverts commit r278659.
llvm-svn: 278711
|
| |
|
|
| |
llvm-svn: 278682
|
| |
|
|
| |
llvm-svn: 278676
|
| |
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D23323
llvm-svn: 278665
|
| |
|
|
|
|
|
|
|
|
|
| |
This adds two new utility functions findLoopControlBlock and findLoopPreheader
to MachineLoop and MachineLoopInfo. These functions are refactored and taken
from the Hexagon target as they are target independent; thus this is intendend to
be a non-functional change.
Differential Revision: https://reviews.llvm.org/D22959
llvm-svn: 278661
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The assembler currently does not check the branch target for CBZ/CBNZ
instructions, which only permit branching forwards with a positive offset. This
adds validation for the branch target to ensure negative PC-relative offsets are
not encoded into the instruction, whether specified as a literal or as an
assembler symbol.
Reviewers: rengolin, t.p.northover
Subscribers: llvm-commits, rengolin
Differential Revision: https://reviews.llvm.org/D23312
llvm-svn: 278659
|
| |
|
|
| |
llvm-svn: 278654
|
| |
|
|
| |
llvm-svn: 278653
|
| |
|
|
| |
llvm-svn: 278652
|
| |
|
|
| |
llvm-svn: 278629
|
| |
|
|
|
|
| |
folding tables.
llvm-svn: 278628
|
| |
|
|
| |
llvm-svn: 278627
|
| |
|
|
|
|
|
|
| |
be zero extended according to SPEC.
Differential Revision: http://reviews.llvm.org/D23489
llvm-svn: 278626
|
| |
|
|
|
|
|
|
|
| |
1. Use shuffle to insert element i1 into vector. The previous implementation was incorrect ( dest_bit OR src_bit , it doesn't clear the bit if src_bit=0 )
2. Improve shuffle i1 vector, use CVT2MASK if supported instead TRUNCATE.
Differential Revision: http://reviews.llvm.org/D23347
llvm-svn: 278623
|
| |
|
|
|
|
|
|
|
|
|
| |
LowerTargetConstantPool is not properly setting the TargetFlag to indicate
desired relocation. Coding error, the offset parameter was omitted, so the
TargetFlag was used as the offset, and the TargetFlag defaulted to zero.
This only affects -fpic compilation, and only those items created in a
Constant Pool, for example a vector of constants. Halide ran into this issue.
llvm-svn: 278614
|
| |
|
|
|
|
|
|
| |
X86InstrInfo::findCommutedOpIndices. Most callers don't check if the instruction is commutable before calling.
This saves us the trouble of ending up in the default of the switch and having to determine if this is an FMA or not.
llvm-svn: 278597
|
| |
|
|
| |
llvm-svn: 278596
|
| |
|
|
| |
llvm-svn: 278595
|
| |
|
|
|
|
| |
(scalar_to_vector))) as the (vzmovl VR256) pattern has higher priority. NFC
llvm-svn: 278594
|
| |
|
|
|
|
| |
patterns over more complex ones that produce better code.
llvm-svn: 278593
|
| |
|
|
|
|
|
|
| |
64-bit and 32-bit elements.
Fixes PR28961.
llvm-svn: 278592
|