| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
- this should fix PR13780
llvm-svn: 163370
|
| |
|
|
|
|
| |
No functional change.
llvm-svn: 163339
|
| |
|
|
| |
llvm-svn: 163309
|
| |
|
|
|
|
|
|
| |
allocations (allocas). Allocas are known to be
disjoint if they are marked by disjoint lifetime markers (@llvm.lifetime.XXX intrinsics).
llvm-svn: 163299
|
| |
|
|
| |
llvm-svn: 163263
|
| |
|
|
| |
llvm-svn: 163258
|
| |
|
|
|
|
| |
MachineInstr.
llvm-svn: 163257
|
| |
|
|
| |
llvm-svn: 163256
|
| |
|
|
|
|
| |
of its constness. Found by gcc48 -Wcast-qual.
llvm-svn: 163254
|
| |
|
|
| |
llvm-svn: 163243
|
| |
|
|
|
|
| |
types. The previous code was making the assumption that the length of the bitmask returned by isConstantSplat was equal to the size of the vector type. Now we first make sure that the splat value has at least the length of the vector lane type, then we only use as many fields as we have available in the splat value.
llvm-svn: 163203
|
| |
|
|
|
|
| |
build time. Similar was previously done for vinserti128/vinsertf128. Add patterns for folding these extract_subvectors with stores.
llvm-svn: 163192
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- CodeGenPrepare pass for identifying div/rem ops
- Backend specifies the type mapping using addBypassSlowDivType
- Enabled only for Intel Atom with O2 32-bit -> 8-bit
- Replace IDIV with instructions which test its value and use DIVB if the value
is positive and less than 256.
- In the case when the quotient and remainder of a divide are used a DIV
and a REM instruction will be present in the IR. In the non-Atom case
they are both lowered to IDIVs and CSE removes the redundant IDIV instruction,
using the quotient and remainder from the first IDIV. However,
due to this optimization CSE is not able to eliminate redundant
IDIV instructions because they are located in different basic blocks.
This is overcome by calculating both the quotient (DIV) and remainder (REM)
in each basic block that is inserted by the optimization and reusing the result
values when a subsequent DIV or REM instruction uses the same operands.
- Test cases check for the presents of the optimization when calculating
either the quotient, remainder, or both.
Patch by Tyler Nowicki!
llvm-svn: 163150
|
| |
|
|
| |
llvm-svn: 163094
|
| |
|
|
|
|
| |
not sign-extend.
llvm-svn: 163086
|
| |
|
|
|
|
|
|
|
| |
zeros or all ones. A vector bool with just ones isn't suitable for masking with.
No test case unfortunately as i couldn't find a target which fit all
the conditions needed to hit this code.
llvm-svn: 163075
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
vector from i1 to some other type. rdar://problem/12210060"
This reverts commit 5dd9e214fb92847e947f9edab170f9b4e52b908f.
Thanks to Duncan for explaining how this should have been done.
Conflicts:
test/CodeGen/X86/vec_select.ll
llvm-svn: 163064
|
| |
|
|
|
|
| |
fast-math mode.
llvm-svn: 163051
|
| |
|
|
| |
llvm-svn: 163049
|
| |
|
|
|
|
|
|
|
|
|
| |
Manage tied operands entirely internally to MachineInstr. This makes it
possible to change the representation of tied operands, as I will do
shortly.
The constraint that tied uses and defs must be in the same order was too
restrictive.
llvm-svn: 163021
|
| |
|
|
|
|
|
|
|
| |
I was too optimistic, inline asm can have tied operands that don't
follow the def order.
Fixes PR13742.
llvm-svn: 162998
|
| |
|
|
|
|
| |
i1 to some other type. rdar://problem/12210060
llvm-svn: 162960
|
| |
|
|
|
|
| |
constants. This is only enabled in unsafe FP math mode, since it does not preserve rounding effects for all such constants.
llvm-svn: 162956
|
| |
|
|
|
|
|
|
|
|
|
| |
vector operands - scalarize the code. ARM is such a target
because it does not support CMOV of vectors. To implement this efficientlyi, we broadcast the condition bit and use a sequence of NAND-OR
to select between the two operands. This is the same sequence we use for targets that don't have vector BLENDs (like SSE2).
rdar://12201387
llvm-svn: 162926
|
| |
|
|
|
|
| |
expanded when it isn't legal.
llvm-svn: 162894
|
| |
|
|
| |
llvm-svn: 162893
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When there are multiple tied use-def pairs on an inline asm instruction,
the tied uses must appear in the same order as the defs.
It is possible to write an LLVM IR inline asm instruction that breaks
this constraint, but there is no reason for a front end to emit the
operands out of order.
The gnu inline asm syntax specifies tied operands as a single read/write
constraint "+r", so ouf of order operands are not possible.
llvm-svn: 162878
|
| |
|
|
|
|
|
|
| |
For normal instructions, isTied() is set automatically by addOperand(),
based on MCInstrDesc, but inline asm has tied operands outside the
descriptor.
llvm-svn: 162869
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These extra flags are not required to properly order the atomic
load/store instructions. SelectionDAGBuilder chains atomics as if they
were volatile, and SelectionDAG::getAtomic() sets the isVolatile bit on
the memory operands of all atomic operations.
The volatile bit is enough to order atomic loads and stores during and
after SelectionDAG.
This means we set mayLoad on atomic_load, mayStore on atomic_store, and
mayLoad+mayStore on the remaining atomic read-modify-write operations.
llvm-svn: 162733
|
| |
|
|
|
|
|
|
|
| |
In SelectionDAGLegalize::ExpandLegalINT_TO_FP, expand INT_TO_FP nodes without
using any f64 operations if f64 is not a legal type.
Patch by Stefan Kristiansson.
llvm-svn: 162728
|
| |
|
|
|
|
| |
Reviewed offline by chandlerc.
llvm-svn: 162623
|
| |
|
|
|
|
|
| |
It is legal to have a register node as an explicit operand, it shouldn't
be counted as an implicit use.
llvm-svn: 162591
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
the case of multiple edges from one block to another.
A simple example is a switch statement with multiple values to the same
destination. The definition of an edge is modified from a pair of blocks to
a pair of PredBlock and an index into the successors.
Also set the weight correctly when building SelectionDAG from LLVM IR,
especially when converting a Switch.
IntegersSubsetMapping is updated to calculate the weight for each cluster.
llvm-svn: 162572
|
| |
|
|
|
|
| |
approach. We need to insert some valid TRANCATE node here.
llvm-svn: 162354
|
| |
|
|
|
|
| |
did getFunction()->getName(). Remove includes of Function.h that are no longer needed.
llvm-svn: 162347
|
| |
|
|
|
|
|
|
| |
SelectionDAG's 'init' has not been called when the SelectionDAGBuilder is
constructed (in SelectionDAGISel's constructor), so this was previously always
initialized with 0.
llvm-svn: 162333
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
IR that hasn't been through SimplifyCFG can look like this:
br i1 %b, label %r, label %r
Make sure we don't create duplicate Machine CFG edges in this case.
Fix the machine code verifier to accept conditional branches with a
single CFG edge.
llvm-svn: 162230
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The DAGCombiner tries to optimise a BUILD_VECTOR by checking if it
consists purely of get_vector_elts from one or two source vectors. If
so, it either makes a concat_vectors node or a shufflevector node.
However, it doesn't check the element type width of the underlying
vector, so if you have this sequence:
Node0: v4i16 = ...
Node1: i32 = extract_vector_elt Node0
Node2: i32 = extract_vector_elt Node0
Node3: v16i8 = BUILD_VECTOR Node1, Node2, ...
It will attempt to:
Node0: v4i16 = ...
NewNode1: v16i8 = concat_vectors Node0, ...
Where this is actually invalid because the element width is completely
different. This causes an assertion failure on DAG legalization stage.
Fix:
If output item type of BUILD_VECTOR differs from input item type.
Make concat_vectors based on input element type and then bitcast it to the output vector type. So the case described above will transformed to:
Node0: v4i16 = ...
NewNode1: v8i16 = concat_vectors Node0, ...
NewNode2: v16i8 = bitcast NewNode1
llvm-svn: 162195
|
| |
|
|
|
|
|
|
|
| |
operations
so other unexpected operations don't slip through. Based on patch by Logan Chien.
PR11786/PR13186.
llvm-svn: 162146
|
| |
|
|
|
|
| |
legalizer may call us with an overly large type.
llvm-svn: 162101
|
| |
|
|
|
|
| |
various rounding modes. Use this to implement SelectionDAG constant folding of FFLOOR, FCEIL, and FTRUNC.
llvm-svn: 161807
|
| |
|
|
|
|
|
| |
handle the cases where the memory value type was illegal.
PR 13111.
llvm-svn: 161565
|
| |
|
|
|
|
|
| |
This adds support for TargetIndex operands during isel. The meaning of
these (index, offset, flags) operands is entirely defined by the target.
llvm-svn: 161453
|
| |
|
|
|
|
|
|
|
| |
This patch is mostly just refactoring a bunch of copy-and-pasted code, but
it also adds a check that the call instructions are readnone or readonly.
That check was already present for sin, cos, sqrt, log2, and exp2 calls, but
it was missing for the rest of the builtins being handled in this code.
llvm-svn: 161282
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The previous change caused fast isel to not attempt handling any calls to
builtin functions. That included things like "printf" and caused some
noticable regressions in compile time. I wanted to avoid having fast isel
keep a separate list of functions that had to be kept in sync with what the
code in SelectionDAGBuilder.cpp was handling. I've resolved that here by
moving the list into TargetLibraryInfo. This is somewhat redundant in
SelectionDAGBuilder but it will ensure that we keep things consistent.
llvm-svn: 161263
|
| |
|
|
|
|
|
|
|
| |
I noticed that SelectionDAGBuilder::visitCall was missing a check for memcmp
in TargetLibraryInfo, so that it would use custom code for memcmp calls even
with -fno-builtin. I also had to add a new -disable-simplify-libcalls option
to llc so that I could write a test for this.
llvm-svn: 161262
|
| |
|
|
|
|
|
|
|
|
| |
Fast isel doesn't currently have support for translating builtin function
calls to target instructions. For embedded environments where the library
functions are not available, this is a matter of correctness and not
just optimization. Most of this patch is just arranging to make the
TargetLibraryInfo available in fast isel. <rdar://problem/12008746>
llvm-svn: 161232
|
| |
|
|
| |
llvm-svn: 161110
|
| |
|
|
| |
llvm-svn: 161061
|
| |
|
|
|
|
| |
to do so.
llvm-svn: 161053
|