| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 72468
|
| |
|
|
| |
llvm-svn: 72467
|
| |
|
|
| |
llvm-svn: 72465
|
| |
|
|
| |
llvm-svn: 72464
|
| |
|
|
| |
llvm-svn: 72456
|
| |
|
|
| |
llvm-svn: 72455
|
| |
|
|
| |
llvm-svn: 72454
|
| |
|
|
|
|
| |
handling for every single opcode.
llvm-svn: 72447
|
| |
|
|
| |
llvm-svn: 72414
|
| |
|
|
|
|
| |
corresponding integer type is legal.
llvm-svn: 72373
|
| |
|
|
|
|
| |
it's late, and I don't have any better ideas at the moment. Fixes PR4257.
llvm-svn: 72363
|
| |
|
|
|
|
|
| |
all results and all operands are legal, so this change shouldn't affect
behavior at all.
llvm-svn: 72359
|
| |
|
|
|
|
|
| |
This leaves around 4000 lines of dead code; I'll clean that up
in subsequent commits.
llvm-svn: 72358
|
| |
|
|
|
|
| |
ExpandExtractFromVectorThroughStack.
llvm-svn: 72351
|
| |
|
|
|
|
|
|
| |
doesn't split legal vector operands. This is necessary because the
type legalization (and therefore, vector splitting) code will be going
away soon.
llvm-svn: 72349
|
| |
|
|
| |
llvm-svn: 72210
|
| |
|
|
|
|
|
|
| |
type, rather than assume that it does. If the operand is not vector, it
shouldn't be run through ScalarizeVectorOp. This fixes one of the
testcases in PR3886.
llvm-svn: 71453
|
| |
|
|
|
|
|
| |
will make it more obvious what it represents, and stop
it being confused with the StoreSize.
llvm-svn: 71349
|
| |
|
|
| |
llvm-svn: 71238
|
| |
|
|
|
|
| |
are legal. Based on a patch by Micah Villmow.
llvm-svn: 71078
|
| |
|
|
| |
llvm-svn: 70764
|
| |
|
|
| |
llvm-svn: 70749
|
| |
|
|
|
|
| |
Changes to take advantage of this will come later.
llvm-svn: 70560
|
| |
|
|
|
|
|
|
| |
-Replace DebugLocTuple's Source ID with CompileUnit's GlobalVariable*
-Remove DwarfWriter::getOrCreateSourceID
-Make necessary changes for the above (fix callsites, etc.)
llvm-svn: 70520
|
| |
|
|
|
|
|
| |
which better identifies what the optimization is doing. And is more flexible for
future uses.
llvm-svn: 70440
|
| |
|
|
|
|
| |
unnecessary.
llvm-svn: 70425
|
| |
|
|
| |
llvm-svn: 70372
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Massive check in. This changes the "-fast" flag to "-O#" in llc. If you want to
use the old behavior, the flag is -O0. This change allows for finer-grained
control over which optimizations are run at different -O levels.
Most of this work was pretty mechanical. The majority of the fixes came from
verifying that a "fast" variable wasn't used anymore. The JIT still uses a
"Fast" flag. I'll change the JIT with a follow-up patch.
llvm-svn: 70343
|
| |
|
|
| |
llvm-svn: 70275
|
| |
|
|
|
|
|
|
|
|
|
| |
use the old behavior, the flag is -O0. This change allows for finer-grained
control over which optimizations are run at different -O levels.
Most of this work was pretty mechanical. The majority of the fixes came from
verifying that a "fast" variable wasn't used anymore. The JIT still uses a
"Fast" flag. I'm not 100% sure if it's necessary to change it there...
llvm-svn: 70270
|
| |
|
|
|
|
| |
no-longer needed workarounds.
llvm-svn: 70234
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
PR2957
ISD::VECTOR_SHUFFLE now stores an array of integers representing the shuffle
mask internal to the node, rather than taking a BUILD_VECTOR of ConstantSDNodes
as the shuffle mask. A value of -1 represents UNDEF.
In addition to eliminating the creation of illegal BUILD_VECTORS just to
represent shuffle masks, we are better about canonicalizing the shuffle mask,
resulting in substantially better code for some classes of shuffles.
llvm-svn: 70225
|
| |
|
|
| |
llvm-svn: 69967
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
ISD::VECTOR_SHUFFLE now stores an array of integers representing the shuffle
mask internal to the node, rather than taking a BUILD_VECTOR of ConstantSDNodes
as the shuffle mask. A value of -1 represents UNDEF.
In addition to eliminating the creation of illegal BUILD_VECTORS just to
represent shuffle masks, we are better about canonicalizing the shuffle mask,
resulting in substantially better code for some classes of shuffles.
A clean up of x86 shuffle code, and some canonicalizing in DAGCombiner is next.
llvm-svn: 69952
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
type as the vector element type: allow them to be of
a wider integer type than the element type all the way
through the system, and not just as far as LegalizeDAG.
This should be safe because it used to be this way
(the old type legalizer would produce such nodes), so
backends should be able to handle it. In fact only
targets which have legal vector types with an illegal
promoted element type will ever see this (eg: <4 x i16>
on ppc). This fixes a regression with the new type
legalizer (vec_splat.ll). Also, treat SCALAR_TO_VECTOR
the same as BUILD_VECTOR. After all, it is just a
special case of BUILD_VECTOR.
llvm-svn: 69467
|
| |
|
|
|
|
|
|
| |
to support replacing a node with another that has a superset of
the result types. Use this instead of calling
ReplaceAllUsesOfValueWith for each value.
llvm-svn: 69209
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
promoted to legal types without changing the type of the vector. This is
following a suggestion from Duncan
(http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-February/019923.html).
The transformation that used to be done during type legalization is now
postponed to DAG legalization. This allows the BUILD_VECTORs to be optimized
and potentially handled specially by target-specific code.
It turns out that this is also consistent with an optimization done by the
DAG combiner: a BUILD_VECTOR and INSERT_VECTOR_ELT may be combined by
replacing one of the BUILD_VECTOR operands with the newly inserted element;
but INSERT_VECTOR_ELT allows its scalar operand to be larger than the
element type, with any extra high bits being implicitly truncated. The
result is a BUILD_VECTOR where one of the operands has a type larger the
the vector element type.
Any code that operates on BUILD_VECTORs may now need to be aware of the
potential type discrepancy between the vector element type and the
BUILD_VECTOR operands. This patch updates all of the places that I could
find to handle that case.
llvm-svn: 68996
|
| |
|
|
| |
llvm-svn: 68981
|
| |
|
|
|
|
| |
No functional changes.
llvm-svn: 68808
|
| |
|
|
|
|
| |
code that uses it by using SelectionDAG::getVTList instead.
llvm-svn: 68744
|
| |
|
|
|
|
|
| |
Note that these are distinct from TargetInstrInfo::INSERT_SUBREG
and TargetInstrInfo::EXTRACT_SUBREG, which are used.
llvm-svn: 68355
|
| |
|
|
|
|
| |
to have access to the line number field. So we convert that info as an operand by custom handling DBG_STOPPOINT in legalize.
llvm-svn: 68329
|
| |
|
|
|
|
| |
operand index in the high bits.
llvm-svn: 67387
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
unnecessary paddings between constant pool entries, larger than necessary alignments (e.g. 8 byte alignment for .literal4 sections), and potentially other issues.
1. ConstantPoolSDNode alignment field is log2 value of the alignment requirement. This is not consistent with other SDNode variants.
2. MachineConstantPool alignment field is also a log2 value.
3. However, some places are creating ConstantPoolSDNode with alignment value rather than log2 values. This creates entries with artificially large alignments, e.g. 256 for SSE vector values.
4. Constant pool entry offsets are computed when they are created. However, asm printer group them by sections. That means the offsets are no longer valid. However, asm printer uses them to determine size of padding between entries.
5. Asm printer uses expensive data structure multimap to track constant pool entries by sections.
6. Asm printer iterate over SmallPtrSet when it's emitting constant pool entries. This is non-deterministic.
Solutions:
1. ConstantPoolSDNode alignment field is changed to keep non-log2 value.
2. MachineConstantPool alignment field is also changed to keep non-log2 value.
3. Functions that create ConstantPool nodes are passing in non-log2 alignments.
4. MachineConstantPoolEntry no longer keeps an offset field. It's replaced with an alignment field. Offsets are not computed when constant pool entries are created. They are computed on the fly in asm printer and JIT.
5. Asm printer uses cheaper data structure to group constant pool entries.
6. Asm printer compute entry offsets after grouping is done.
7. Change JIT code to compute entry offsets on the fly.
llvm-svn: 66875
|
| |
|
|
| |
llvm-svn: 66867
|
| |
|
|
| |
llvm-svn: 66866
|
| |
|
|
|
|
| |
on the number of times a std::string is created and copied.
llvm-svn: 66396
|
| |
|
|
| |
llvm-svn: 66357
|
| |
|
|
| |
llvm-svn: 65482
|
| |
|
|
|
|
|
|
| |
getGlobalVariablesUsing and replaced it something readable. It eliminated use of slow UniqueVector and replaced it with StringMap, SmallVector, and DenseMap, etc. It also fixed some non-deterministic behavior.
This is a very minor compile time win.
llvm-svn: 65438
|