| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
Enabled constant canonicalization for all constants.
Improved combining of constant vectors.
llvm-svn: 249993
|
| |
|
|
|
|
|
|
| |
Enable constant folding for vector splats as well as scalars.
Enable constant canonicalization for all scalar and vector constants.
llvm-svn: 249978
|
| |
|
|
|
|
| |
wineh-parent is dead, so is ValueOrMBB.
llvm-svn: 249920
|
| |
|
|
|
|
|
|
|
|
|
| |
The new implementation works at least as well as the old implementation
did.
Also delete the associated preparation tests. They don't exercise
interesting corner cases of the new implementation. All the codegen
tests of the EH tables have already been ported.
llvm-svn: 249918
|
| |
|
|
|
|
|
|
|
|
| |
Win64"""
This reverts commit r249794.
Apparently my checkouts are full of unexpected surprises today.
llvm-svn: 249796
|
| |
|
|
|
|
|
|
| |
This reverts commit r249032.
TODO write commit msg
llvm-svn: 249794
|
| |
|
|
|
|
| |
I called the wrong MachineBasicBlock::addLiveIn() overload.
llvm-svn: 249786
|
| |
|
|
|
|
|
|
|
| |
I'll be using the function in a similar combine for AArch64. The helper was
also improved to handle undef values.
Part of http://reviews.llvm.org/D13442
llvm-svn: 249572
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Set the pad MBB as a funclet entry for CoreCLR as well as MSVCCXX, and
update state numbering to put the catchpad block rather than its normal
successor into the unwind map.
Reviewers: majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D13492
llvm-svn: 249569
|
| |
|
|
|
|
| |
This will support the Clang __exception_code intrinsic.
llvm-svn: 249492
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our current emission strategy is to emit the funclet prologue in the
CatchPad's normal destination. This is problematic because
intra-funclet control flow to the normal destination is not erroneous
and results in us reevaluating the prologue if said control flow is
taken.
Instead, use the CatchPad's location for the funclet prologue. This
correctly models our desire to have unwind edges evaluate the prologue
but edges to the normal destination result in typical control flow.
Differential Revision: http://reviews.llvm.org/D13424
llvm-svn: 249483
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Assign one state number per handler/funclet, tracking parent state,
handler type, and catch type token.
State numbers are arranged such that ancestors have lower state numbers
than their descendants.
Reviewers: majnemer, andrew.w.kaylor, rnk
Subscribers: pgavlin, AndyAyers, llvm-commits
Differential Revision: http://reviews.llvm.org/D13450
llvm-svn: 249457
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- Add CoreCLR to if/else ladders and switches as appropriate.
- Rename isMSVCEHPersonality to isFuncletEHPersonality to better
reflect what it captures.
Reviewers: majnemer, andrew.w.kaylor, rnk
Subscribers: pgavlin, AndyAyers, llvm-commits
Differential Revision: http://reviews.llvm.org/D13449
llvm-svn: 249455
|
| |
|
|
|
|
| |
We already check for LandingPadInst two lines above.
llvm-svn: 249280
|
| |
|
|
|
|
|
|
| |
Updated the FADD combines to work with vectors as well as scalars.
Differential Revision: http://reviews.llvm.org/D13416
llvm-svn: 249251
|
| |
|
|
|
|
|
|
|
|
| |
visitSIGN_EXTEND_INREG calls SelectionDAG::getNode to constant fold scalar constants but handles vector constants itself, despite getNode being capable of dealing with them.
This required a minor change to the getNode implementation to actually deal with cases where the scalars of a BUILD_VECTOR were wider integers than the vector type - which was the only extra ability of the visitSIGN_EXTEND_INREG implementation.
No codegen intended and all existing tests remain the same.
llvm-svn: 249236
|
| |
|
|
|
|
|
|
|
| |
Catchret transfers control from a catch funclet to an earlier funclet.
However, it is not completely clear which funclet the catchret target is
part of. Make this clear by stapling the catchret target's funclet
membership onto the CATCHRET SDAG node.
llvm-svn: 249052
|
| |
|
|
| |
llvm-svn: 249033
|
| |
|
|
|
|
| |
It broke; LLVM :: CodeGen__Generic__2009-11-16-BadKillsCrash.ll
llvm-svn: 249032
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Win64 unwinder disassembles forwards from each PC to try to
determine if this PC is in an epilogue. If so, it skips calling the EH
personality function for that frame. Typically, this means you cannot
catch an exception in the same frame that you threw it, because 'throw'
calls a noreturn runtime function.
Previously we avoided this problem with the TrapUnreachable
TargetOption, but that's a much bigger hammer than we need. All we need
is a 1 byte non-epilogue instruction right after the call. Instead,
what we got was an unconditional branch to a shared block containing the
ud2, potentially 7 bytes instead of 1. So, this reverts r206684, which
added TrapUnreachable, and replaces it with something better.
The new code pattern matches for invoke/call followed by unreachable and
inserts an int3 into the DAG. To be 100% watertight, we would need to
insert SEH_Epilogue instructions into all basic blocks ending in a call
with no terminators or successors, but in practice this is unlikely to
come up.
llvm-svn: 248959
|
| |
|
|
| |
llvm-svn: 248933
|
| |
|
|
|
|
|
|
|
|
|
| |
Summary:
Funclets have been turned into functions by the time they hit the object
file. Make sure that they have decent names for the symbol table and
CFI directives explaining how to reason about their prologues.
Differential Revision: http://reviews.llvm.org/D13261
llvm-svn: 248824
|
| |
|
|
|
|
|
| |
Previously we were hijacking the old LandingPadInfo data structures to
communicate our state numbers. Now we don't need that anymore.
llvm-svn: 248763
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When AA is being used, non-aliasing stores are canonicalized to use the same
chain, and DAGCombiner::getStoreMergeAndAliasCandidates can take advantage of
this by looking only as users of a store's chain operand. However, user
iteration is not result-number specific, we need to check that the use is as a
chain operand, and not via some other operand. It is certainly possible to have
another potentially-aliasing store, which shares the first's base pointer, and
uses the first's chain's node via some other operand.
Failure to catch this situation caused, at least in the included test case, an
assert later because the relative sequence-number ordering caused later
replacement to create a cycle in the DAG.
llvm-svn: 248698
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Print simple operands inline instead of their pointer/value number.
Simple operands are SDNodes without predecessors like Constant(FP), Register,
UNDEF. This unifies the behaviour with dumpr() which was already doing this.
Previously:
t0: ch = EntryToken
t1: i64 = Register %vreg0
t2: i64,ch = CopyFromReg t0, t1
t3: i64 = Constant<1>
t4: i64 = add t2, t3
t5: i64 = Constant<2>
t6: i64 = add t2, t5
t10: i64 = undef
t11: i8,ch = load t0, t2, t10<LD1[%tmp81]>
t12: i8,ch = load t0, t4, t10<LD1[%tmp10]>
t13: i8,ch = load t0, t6, t10<LD1[%tmp12]>
Now:
t0: ch = EntryToken
t2: i64,ch = CopyFromReg t0, Register:i64 %vreg0
t4: i64 = add t2, Constant:i64<1>
t6: i64 = add t2, Constant:i64<2>
t11: i8,ch = load<LD1[%tmp81]> t0, t2, undef:i64
t12: i8,ch = load<LD1[%tmp10]> t0, t4, undef:i64
t13: i8,ch = load<LD1[%tmp12]> t0, t6, undef:i64
Differential Revision: http://reviews.llvm.org/D12567
llvm-svn: 248628
|
| |
|
|
|
|
| |
This is the simpler check. NFC.
llvm-svn: 248625
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
access TLI hook (PR21711)
This is a redo of D7208 ( r227242 - http://llvm.org/viewvc/llvm-project?view=revision&revision=227242 ).
The patch was reverted because an AArch64 target could infinite loop after the change in DAGCombiner
to merge vector stores. That happened because AArch64's allowsMisalignedMemoryAccesses() wasn't telling
the truth. It reported all unaligned memory accesses as fast, but then split some 128-bit unaligned
accesses up in performSTORECombine() because they are slow.
This patch attempts to fix the problem in AArch's allowsMisalignedMemoryAccesses() while preserving
existing (perhaps questionable) lowering behavior.
The x86 test shows that store merging is working as intended for a target with fast 32-byte unaligned
stores.
Differential Revision: http://reviews.llvm.org/D12635
llvm-svn: 248622
|
| |
|
|
|
|
|
|
| |
Fixes the overflow case of llvm.*absdiff intrinsic also updats the tests and LangRef.rst accordingly.
Differential Revision: http://reviews.llvm.org/D11678
llvm-svn: 248483
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the stores are storing values from loads which partially
alias the stores, we could end up placing the merged loads
and stores on the same chain which has the potential to break.
Each store may have a different chain dependency on only some
of the original loads. Create a new TokenFactor to capture all
of the required dependencies of the stores rather than assuming
all stores can use the same chain.
The testcase is a situation where this happens, although
it does not have an observable change from this. The DAG nodes
just happened to not be reordered before despite this missing
chain dependency.
This is based on an off-list report for an out of tree target
which regressed due to r246307 and I haven't managed to find a case
where the nodes do end up reordered with an in tree target.
llvm-svn: 248468
|
| |
|
|
|
|
| |
Fixed the issue that when there is an edge from the jump table to the default statement, we should check it directly instead of checking if the sibling of the jump table header is a successor of the jump table header, which may not be the default statment but a successor of it.
llvm-svn: 248354
|
| |
|
|
| |
llvm-svn: 248264
|
| |
|
|
| |
llvm-svn: 248263
|
| |
|
|
| |
llvm-svn: 248261
|
| |
|
|
|
|
|
|
|
|
| |
This patch adds support for combining patterns such as (FMUL(FADD(1.0, x), y)) and (FMUL(FSUB(x, 1.0), y)) to their FMA equivalents.
This is useful in particular for linear interpolation cases such as (FADD(FMUL(x, t), FMUL(y, FSUB(1.0, t))))
Differential Revision: http://reviews.llvm.org/D13003
llvm-svn: 248210
|
| |
|
|
|
|
| |
Based on feedback for D13003.
llvm-svn: 248206
|
| |
|
|
|
|
| |
Because mod is always exact, this function should have never taken a rounding mode argument. The actual implementation still has issues, which I'll look at resolving in a subsequent patch.
llvm-svn: 248195
|
| |
|
|
| |
llvm-svn: 248190
|
| |
|
|
|
|
| |
This fixes problems where two nodes have persistent debug id 0 assigned.
llvm-svn: 248182
|
| |
|
|
|
|
|
|
|
| |
If storing multiple FP constants, some subset of the stores
would be replaced with integers due to visit order, so
MergeConsecutiveStores would only partially merge
these.
llvm-svn: 248169
|
| |
|
|
| |
llvm-svn: 248168
|
| |
|
|
|
|
| |
extra times. NFC
llvm-svn: 248140
|
| |
|
|
|
|
|
|
|
| |
They mostly clutter the output while it is still possible to see which
node has multiple users without them.
Differential Revision: http://reviews.llvm.org/D12569
llvm-svn: 248013
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
t0 = EntryToken:ch
t0: <multiple use>
t0: <multiple use>
t1 = CopyFromReg:v4f32,ch t0, Register:v4f32 %vreg0
t25 = IMPLICIT_DEF:v4f32
t26 = HADDPSrr:v4f32 t1, t25
t23 = CopyToReg:ch,glue t0, Register:v4f32 %XMM0, t26
t23: <multiple use>
t23: <multiple use>
t24 = RETQ:ch Register:v4f32 %XMM0, t23, t23:1
After:
t0: <multiple use>
t0: <multiple use>
t1 = CopyFromReg:v4f32,ch t0, Register:v4f32 %vreg0
t26 = X86ISD::FHADD:v4f32 t1, undef:v4f32
t23 = CopyToReg:ch,glue t0, Register:v4f32 %XMM0, t26
t23: <multiple use>
t21 = TargetConstant:i16<0>
t23: <multiple use>
t24 = X86ISD::RET_FLAG:ch t23, t21, Register:v4f32 %XMM0, t23:1
Differential Revision: http://reviews.llvm.org/D12568
llvm-svn: 248012
|
| |
|
|
|
|
|
|
| |
You can show them with the new -dag-dump-verbose switch.
Differential Revision: http://reviews.llvm.org/D12566
llvm-svn: 248011
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This gives us more human readable numbers to identify nodes in debug
dumps.
Before:
0x7fcbd9700160: ch = EntryToken
0x7fcbd985c7c8: i64 = Register %RAX
...
0x7fcbd9700160: <multiple use>
0x7fcbd985c578: i64,ch = MOV64rm 0x7fcbd985c6a0, 0x7fcbd985cc68, 0x7fcbd985c200, 0x7fcbd985cd90, 0x7fcbd985ceb8, 0x7fcbd9700160<Mem:LD8[@foo]> [ORD=2]
0x7fcbd985c8f0: ch,glue = CopyToReg 0x7fcbd9700160, 0x7fcbd985c7c8, 0x7fcbd985c578 [ORD=3]
0x7fcbd985c7c8: <multiple use>
0x7fcbd985c8f0: <multiple use>
0x7fcbd985c8f0: <multiple use>
0x7fcbd985ca18: ch = RETQ 0x7fcbd985c7c8, 0x7fcbd985c8f0, 0x7fcbd985c8f0:1 [ORD=3]
Now:
t0: ch = EntryToken
t5: i64 = Register %RAX
...
t0: <multiple use>
t3: i64,ch = MOV64rm t10, t12, t11, t13, t14, t0<Mem:LD8[@foo]> [ORD=2]
t6: ch,glue = CopyToReg t0, t5, t3 [ORD=3]
t5: <multiple use>
t6: <multiple use>
t6: <multiple use>
t7: ch = RETQ t5, t6, t6:1 [ORD=3]
Differential Revision: http://reviews.llvm.org/D12564
llvm-svn: 248010
|
| |
|
|
| |
llvm-svn: 247969
|
| |
|
|
|
|
|
|
|
|
| |
Clang now passes the adjectives as an argument to catchpad.
Getting the CatchObj working is simply a matter of threading another
static alloca through codegen, first as an alloca, then as a frame
index, and finally as a frame offset.
llvm-svn: 247844
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After D10403, we had FMF in the DAG but disabled by default. Nick reported no crashing errors after some stress testing,
so I enabled them at r243687. However, Escha soon notified us of a bug not covered by any in-tree regression tests:
if we don't propagate the flags, we may fail to CSE DAG nodes because differing FMF causes them to not match. There is
one test case in this patch to prove that point.
This patch hopes to fix or leave a 'TODO' for all of the in-tree places where we create nodes that are FMF-capable. I
did this by putting an assert in SelectionDAG.getNode() to find any FMF-capable node that was being created without FMF
( D11807 ). I then ran all regression tests and test-suite and confirmed that everything passes.
This patch exposes remaining work to get DAG FMF to be fully functional: (1) add the flags to non-binary nodes such as
FCMP, FMA and FNEG; (2) add the flags to intrinsics; (3) use the flags as conditions for transforms rather than the
current global settings.
Differential Revision: http://reviews.llvm.org/D12095
llvm-svn: 247815
|
| |
|
|
|
|
|
|
| |
warning on them having always_inline attribute for reasons I don't fully
understand -- static functions are just as inlinable as inline
functions in terms of linkage.
llvm-svn: 247334
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
folding vectors
Summary:
The BUILD_VECTOR node will truncate its operators to match the
type. We need to take this into account when constant folding -
we need to perform a truncation before constant folding the elements.
This is because the upper bits can change the result, depending on
the operation type (for example this is the case for min/max).
This change also adds a regression test.
Reviewers: jmolloy
Subscribers: jmolloy, llvm-commits
Differential Revision: http://reviews.llvm.org/D12697
llvm-svn: 247265
|