| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
* wrap code blocks in \code ... \endcode;
* refer to parameter names in paragraphs correctly (\arg is not what most
people want -- it starts a new paragraph).
llvm-svn: 163790
|
| |
|
|
|
|
| |
byte represent 8 instructions and the reg modRM byte represents up to 64 instructions. Reduces modRM table from 43k entreis to 25k entries. Based on a patch from Manman Ren.
llvm-svn: 163774
|
| |
|
|
| |
llvm-svn: 163726
|
| |
|
|
| |
llvm-svn: 163721
|
| |
|
|
|
|
| |
unknown def inherits. Make tblgen check for that class, rather than checking for the def itself.
llvm-svn: 163664
|
| |
|
|
|
|
| |
list of registers every time we want to look up a register by name.
llvm-svn: 163659
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sub-register lane masks are bitmasks that can be used to determine if
two sub-registers of a virtual register will overlap. For example, ARM's
ssub0 and ssub1 sub-register indices don't overlap each other, but both
overlap dsub0 and qsub0.
The lane masks will be accurate on most targets, but on targets that use
sub-register indexes in an irregular way, the masks may conservatively
report that two sub-register indices overlap when the eventually
allocated physregs don't.
Irregular register banks also mean that the bits in a lane mask can't be
mapped onto register units, but the concept is similar.
llvm-svn: 163630
|
| |
|
|
|
|
|
| |
Preserve the Composites map in the CodeGenSubRegIndex class so it can be
used to determine which sub-register indices can actually be composed.
llvm-svn: 163629
|
| |
|
|
|
|
|
|
| |
Apparently, NumSubRegIndices was completely unused before. Adjust it by
one to include the null subreg index, just like getNumRegs() includes
the null register.
llvm-svn: 163628
|
| |
|
|
|
|
| |
table size.
llvm-svn: 163594
|
| |
|
|
| |
llvm-svn: 163501
|
| |
|
|
|
|
|
|
| |
hits to the directory.
For example, which('loop-convert') returns 'loop-convert' when the directory 'loop-convert' exists.
llvm-svn: 163469
|
| |
|
|
|
|
|
|
|
| |
matches without using regular expressions."
Turns out I did not need it after all. If we find a use for it in the future, we
can resurrect it.
llvm-svn: 163457
|
| |
|
|
|
|
| |
Patch by Ivan Llopard!
llvm-svn: 163424
|
| |
|
|
|
|
| |
without using regular expressions.
llvm-svn: 163371
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- This patch is inspired by the failure of the following code snippet
which is used to convert enumerable values into encoding bits to
improve the readability of td files.
class S<int s> {
bits<2> V = !if(!eq(s, 8), {0, 0},
!if(!eq(s, 16), {0, 1},
!if(!eq(s, 32), {1, 0},
!if(!eq(s, 64), {1, 1}, {?, ?}))));
}
Later, PR8330 is found to report not exactly the same bug relevant
issue to bit/bits values.
- Instead of resolving bit/bits values separately through
resolveBitReference(), this patch adds getBit() for all Inits and
resolves bit value by resolving plus getting the specified bit. This
unifies the resolving of bit with other values and removes redundant
logic for resolving bit only. In addition,
BitsInit::resolveReferences() is optimized to take advantage of this
origanization by resolving VarBitInit's variable reference first and
then getting bits from it.
- The type interference in '!if' operator is revised to support possible
combinations of int and bits/bit in MHS and RHS.
- As there may be illegal assignments from integer value to bit, says
assign 2 to a bit, but we only check this during instantiation in some
cases, e.g.
bit V = !if(!eq(x, 17), 0, 2);
Verbose diagnostic message is generated when invalid value is
resolveed to help locating the error.
- PR8330 is fixed as well.
llvm-svn: 163360
|
| |
|
|
|
|
|
| |
This Operand type takes a default argument, and is initialized to
this value if it does not appear in a patter.
llvm-svn: 163315
|
| |
|
|
|
|
|
|
| |
allocations (allocas). Allocas are known to be
disjoint if they are marked by disjoint lifetime markers (@llvm.lifetime.XXX intrinsics).
llvm-svn: 163299
|
| |
|
|
|
|
| |
the SubtargetInfoKV tables. Found by gcc48 -Wcast-qual.
llvm-svn: 163251
|
| |
|
|
| |
llvm-svn: 163187
|
| |
|
|
| |
llvm-svn: 163186
|
| |
|
|
|
|
|
| |
implementation does not co-exist well with how the sideeffect and alignstack
attributes are handled. The reverts r161641.
llvm-svn: 163174
|
| |
|
|
|
|
|
|
|
| |
This doesn't seem ideal, perhaps we could just keep the llvm_site_cfg and have
other config (clang and clang-tools-extra) derive their site_cfg from that.
Suggestions/complaints/ideas welcome.
llvm-svn: 163171
|
| |
|
|
| |
llvm-svn: 163131
|
| |
|
|
| |
llvm-svn: 163125
|
| |
|
|
|
|
|
| |
the NumMCOperands argument to the GetMCInstOperandNum() function that is set
to the number of MCOperands this asm operand mapped to.
llvm-svn: 163124
|
| |
|
|
|
|
| |
MCTargetAsmParser class.
llvm-svn: 163122
|
| |
|
|
| |
llvm-svn: 163119
|
| |
|
|
| |
llvm-svn: 163118
|
| |
|
|
| |
llvm-svn: 163104
|
| |
|
|
|
|
|
|
|
|
| |
MatchInstructionImpl() function.
These values are used by the ConvertToMCInst() function to index into the
ConversionTable. The values are also needed to call the GetMCInstOperandNum()
function.
llvm-svn: 163101
|
| |
|
|
|
|
| |
function nowadays.
llvm-svn: 163030
|
| |
|
|
| |
llvm-svn: 162999
|
| |
|
|
|
|
|
| |
the ConvertToMCInst() return void, rather then a bool. Update all the cvt
functions as well.
llvm-svn: 162961
|
| |
|
|
| |
llvm-svn: 162946
|
| |
|
|
| |
llvm-svn: 162945
|
| |
|
|
|
|
| |
an 80-column violation in the generated code. No functional change intended.
llvm-svn: 162944
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AsmMatcherEmitter. This function maps inline assembly operands to MCInst
operands.
For example, '__asm mov j, eax' is represented by the follow MCInst:
<MCInst 1460 <MCOperand Reg:0> <MCOperand Imm:1> <MCOperand Reg:0>
<MCOperand Expr:(j)> <MCOperand Reg:0> <MCOperand Reg:43>>
The first 5 MCInst operands are a result of j matching as a memory operand
consisting of a BaseReg (Reg:0), MemScale (Imm:1), MemIndexReg(Reg:0),
Expr (Expr:(j), and a MemSegReg (Reg:0). The 6th MCInst operand represents
the eax register (Reg:43).
This translation is necessary to determine the Input and Output Exprs. If a
single asm operand maps to multiple MCInst operands, the index of the first
MCInst operand is returned. Ideally, it would return the operand we really
care out (i.e., the Expr:(j) in this case), but I haven't found an easy way
of doing this yet.
llvm-svn: 162920
|
| |
|
|
|
|
|
|
|
|
| |
Adding arbitrary records to ARM.td would break
basic-arm-instructions.s because selection of nop vs mov r0,r0 was
ambiguous (this will be tested by a subsequent addition to ARM.td).
An imperfect but sensible fix is to give precedence to match rules
that have more constraints.
llvm-svn: 162824
|
| |
|
|
|
|
|
| |
Both single-instruction and multi-instruction patterns can be checked
for missing mayLoad / mayStore, and hasSideEffects flags.
llvm-svn: 162734
|
| |
|
|
|
|
| |
Reviewed offline by chandlerc.
llvm-svn: 162623
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, instructions without a primary patterns wouldn't get their
properties inferred. Now, we use all single-instruction patterns for
inference, including 'def : Pat<>' instances.
This causes a lot of instruction flags to change.
- Many instructions no longer have the UnmodeledSideEffects flag because
their flags are now inferred from a pattern.
- Instructions with intrinsics will get a mayStore flag if they already
have UnmodeledSideEffects and a mayLoad flag if they already have
mayStore. This is because intrinsics properties are linear.
- Instructions with atomic_load patterns get a mayStore flag because
atomic loads can't be reordered. The correct workaround is to create
pseudo-instructions instead of using normal loads. PR13693.
llvm-svn: 162614
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instructions are now only marked as variadic if they use variable_ops in
their ins list.
A variadic SDNode is typically used for call nodes that have the call
arguments as operands.
A variadic MachineInstr can actually encode a variable number of
operands, for example ARM's stm/ldm instructions. A call instruction
does not have to be variadic. The call argument registers are added as
implicit operands.
This change remove the MCID::Variadic flags from most call and return
instructions, allowing us to better verify their operands.
llvm-svn: 162599
|
| |
|
|
|
|
|
|
|
| |
It is now allowed to explicitly set hasSideEffects, mayStore, and
mayLoad on instructions with patterns.
Verify that the patterns are consistent with the explicit flags.
llvm-svn: 162569
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Emit TableGen errors if guessInstructionProperties is 0 and
instruction properties can't be inferred from patterns.
Allow explicit instruction properties even when they can be inferred.
This patch doesn't change the TableGen output. Redundant properties
are not yet verified because the tree has errors.
llvm-svn: 162516
|
| |
|
|
|
|
|
| |
Keep track of the set/unset state of these bits along with their
true/false values, but treat '?' as '0' for now.
llvm-svn: 162461
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Currently, TableGen just guesses instruction properties when it can't
infer them form patterns.
This adds a guessInstructionProperties flag to the instruction set
definition that will be used to disable guessing. The flag is intended
as a migration aid. It will be removed again when no more targets need
their properties guessed.
llvm-svn: 162460
|
| |
|
|
| |
llvm-svn: 162446
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When reporting an error for a defm, we would previously only report the
location of the outer defm, which is not always where the error is.
Now we also print the location of the expanded multiclass defs:
lib/Target/X86/X86InstrSSE.td:2902:12: error: foo
defm ADD : basic_sse12_fp_binop_s<0x58, "add", fadd, SSE_ALU_ITINS_S>,
^
lib/Target/X86/X86InstrSSE.td:2801:11: note: instantiated from multiclass
defm PD : sse12_fp_packed<opc, !strconcat(OpcodeStr, "pd"), OpNode, VR128,
^
lib/Target/X86/X86InstrSSE.td:194:5: note: instantiated from multiclass
def rm : PI<opc, MRMSrcMem, (outs RC:$dst), (ins RC:$src1, x86memop:$src2),
^
llvm-svn: 162409
|
| |
|
|
|
|
|
|
|
|
|
|
| |
No change in interface or functionality. Purely under-the-hood
details of the generated function that change.
The X86 assembly parser is reduced in size by over 15% and ARM by
over 10%.
No performance change by my measurements.
llvm-svn: 162337
|