forked from OSchip/llvm-project
Spelling fix: consequtive -> consecutive.
llvm-svn: 125563
This commit is contained in:
parent
e3dc1707b5
commit
75b5d27b84
|
@ -133,7 +133,7 @@ both 32-bit and 64-bit code generation.
|
|||
=head2 The "CHECK-NEXT:" directive
|
||||
|
||||
Sometimes you want to match lines and would like to verify that matches
|
||||
happen on exactly consequtive lines with no other lines in between them. In
|
||||
happen on exactly consecutive lines with no other lines in between them. In
|
||||
this case, you can use CHECK: and CHECK-NEXT: directives to specify this. If
|
||||
you specified a custom check prefix, just use "<PREFIX>-NEXT:". For
|
||||
example, something like this works as you'd expect:
|
||||
|
|
|
@ -604,7 +604,7 @@ name="FileCheck-CHECK-NEXT">The "CHECK-NEXT:" directive</a></div>
|
|||
<div class="doc_text">
|
||||
|
||||
<p>Sometimes you want to match lines and would like to verify that matches
|
||||
happen on exactly consequtive lines with no other lines in between them. In
|
||||
happen on exactly consecutive lines with no other lines in between them. In
|
||||
this case, you can use CHECK: and CHECK-NEXT: directives to specify this. If
|
||||
you specified a custom check prefix, just use "<PREFIX>-NEXT:". For
|
||||
example, something like this works as you'd expect:</p>
|
||||
|
|
|
@ -1474,7 +1474,7 @@ results as soon as they are no longer needed.</li>
|
|||
<li><b>Pipeline the execution of passes on the program</b> - The
|
||||
<tt>PassManager</tt> attempts to get better cache and memory usage behavior out
|
||||
of a series of passes by pipelining the passes together. This means that, given
|
||||
a series of consequtive <a href="#FunctionPass"><tt>FunctionPass</tt></a>'s, it
|
||||
a series of consecutive <a href="#FunctionPass"><tt>FunctionPass</tt></a>'s, it
|
||||
will execute all of the <a href="#FunctionPass"><tt>FunctionPass</tt></a>'s on
|
||||
the first function, then all of the <a
|
||||
href="#FunctionPass"><tt>FunctionPass</tt></a>es on the second function,
|
||||
|
|
|
@ -57,7 +57,7 @@ protected:
|
|||
/// it, so that the end iterator actually points to valid memory.
|
||||
unsigned CurArraySize;
|
||||
|
||||
// If small, this is # elts allocated consequtively
|
||||
// If small, this is # elts allocated consecutively
|
||||
unsigned NumElements;
|
||||
unsigned NumTombstones;
|
||||
|
||||
|
|
|
@ -1012,7 +1012,7 @@ void AsmPrinter::EmitJumpTableInfo() {
|
|||
}
|
||||
}
|
||||
|
||||
// On some targets (e.g. Darwin) we want to emit two consequtive labels
|
||||
// On some targets (e.g. Darwin) we want to emit two consecutive labels
|
||||
// before each jump table. The first label is never referenced, but tells
|
||||
// the assembler and linker the extents of the jump table object. The
|
||||
// second label is actually referenced by the code.
|
||||
|
|
|
@ -699,7 +699,7 @@ static bool CompareMBBNumbers(const MachineBasicBlock *LHS,
|
|||
/// machine function, it upsets all of the block numbers. Renumber the blocks
|
||||
/// and update the arrays that parallel this numbering.
|
||||
void ARMConstantIslands::UpdateForInsertedWaterBlock(MachineBasicBlock *NewBB) {
|
||||
// Renumber the MBB's to keep them consequtive.
|
||||
// Renumber the MBB's to keep them consecutive.
|
||||
NewBB->getParent()->RenumberBlocks(NewBB);
|
||||
|
||||
// Insert a size into BBSizes to align it properly with the (newly
|
||||
|
|
|
@ -165,7 +165,7 @@ Instruction *InstCombiner::visitLoadInst(LoadInst &LI) {
|
|||
if (LI.isVolatile()) return 0;
|
||||
|
||||
// Do really simple store-to-load forwarding and load CSE, to catch cases
|
||||
// where there are several consequtive memory accesses to the same location,
|
||||
// where there are several consecutive memory accesses to the same location,
|
||||
// separated by a few arithmetic operations.
|
||||
BasicBlock::iterator BBI = &LI;
|
||||
if (Value *AvailableVal = FindAvailableLoadedValue(Op, LI.getParent(), BBI,6))
|
||||
|
|
|
@ -273,7 +273,7 @@ bool LoopIdiomRecognize::processLoopStore(StoreInst *SI, const SCEV *BECount) {
|
|||
return false;
|
||||
|
||||
// If the stored value is a byte-wise value (like i32 -1), then it may be
|
||||
// turned into a memset of i8 -1, assuming that all the consequtive bytes
|
||||
// turned into a memset of i8 -1, assuming that all the consecutive bytes
|
||||
// are stored. A store of i32 0x01020304 can never be turned into a memset.
|
||||
if (Value *SplatValue = isBytewiseValue(StoredVal))
|
||||
if (processLoopStoreOfSplatValue(StorePtr, StoreSize, SI->getAlignment(),
|
||||
|
|
|
@ -352,7 +352,7 @@ INITIALIZE_PASS_END(MemCpyOpt, "memcpyopt", "MemCpy Optimization",
|
|||
|
||||
/// tryMergingIntoMemset - When scanning forward over instructions, we look for
|
||||
/// some other patterns to fold away. In particular, this looks for stores to
|
||||
/// neighboring locations of memory. If it sees enough consequtive ones, it
|
||||
/// neighboring locations of memory. If it sees enough consecutive ones, it
|
||||
/// attempts to merge them together into a memcpy/memset.
|
||||
Instruction *MemCpyOpt::tryMergingIntoMemset(Instruction *StartInst,
|
||||
Value *StartPtr, Value *ByteVal) {
|
||||
|
|
Loading…
Reference in New Issue