| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 96497
|
|
|
|
|
|
|
| |
and add a sparc implementation that knows about delay slots. Patch by
Nathan Keynes!
llvm-svn: 96492
|
|
|
|
| |
llvm-svn: 96466
|
|
|
|
| |
llvm-svn: 96464
|
|
|
|
|
|
| |
tblgen splatted code into the implementation.
llvm-svn: 96460
|
|
|
|
|
|
|
| |
I'd like to eventually rip it out, but for now producing the
same selections as the old matcher is more important.
llvm-svn: 96458
|
|
|
|
|
|
| |
resolving a fixme.
llvm-svn: 96457
|
|
|
|
|
|
| |
functionality change.
llvm-svn: 96453
|
|
|
|
|
|
|
| |
'ischaincompatible' when a pattern has more than one input chain. Need
to do some commenting and cleanup now that I understand how this works.
llvm-svn: 96443
|
|
|
|
| |
llvm-svn: 96437
|
|
|
|
|
|
|
| |
variables. Use the fancy OpNo variable instead of i,
which has the right index including chains.
llvm-svn: 96436
|
|
|
|
| |
llvm-svn: 96433
|
|
|
|
| |
llvm-svn: 96422
|
|
|
|
|
|
|
| |
for evaluating complex patterns. Some cleanup has to happen before
this can be used though.
llvm-svn: 96419
|
|
|
|
| |
llvm-svn: 96416
|
|
|
|
|
|
| |
record all their results.
llvm-svn: 96412
|
|
|
|
|
|
| |
does the same thing as getComplexPatternInfo.
llvm-svn: 96411
|
|
|
|
| |
llvm-svn: 96409
|
|
|
|
|
|
|
|
|
|
| |
into a roundss intrinsic, producing a cyclic dag. The root cause
of this is badness handling ComplexPattern nodes in the old dagisel
that I noticed through inspection. Eliminate a copy of the of the
code that handled ComplexPatterns by making EmitChildMatchCode call
into EmitMatchCode.
llvm-svn: 96408
|
|
|
|
|
|
| |
need to scan the entire subtree of the pattern anymore.
llvm-svn: 96369
|
|
|
|
|
|
|
|
|
| |
use and only call IsProfitableToFold/IsLegalToFold on the load
being folded, like the old dagiselemitter does. This
substantially simplifies the code and improves opportunities for
sharing.
llvm-svn: 96368
|
|
|
|
|
|
|
|
| |
with chains. On interior nodes that lead up to them, we just directly
check that there is a single use. This generates slightly more
efficient code.
llvm-svn: 96366
|
|
|
|
| |
llvm-svn: 96337
|
|
|
|
|
|
|
| |
build if enabled, it will fail with constness issues. I'll resolve
these next.
llvm-svn: 96336
|
|
|
|
| |
llvm-svn: 96334
|
|
|
|
| |
llvm-svn: 96333
|
|
|
|
| |
llvm-svn: 96332
|
|
|
|
|
|
| |
(isprofitable|islegal)tofold checks.
llvm-svn: 96331
|
|
|
|
|
|
|
|
| |
IsLegalToFold and IsProfitableToFold. The generic version of the later simply checks whether the folding candidate has a single use.
This allows the target isel routines more flexibility in deciding whether folding makes sense. The specific case we are interested in is folding constant pool loads with multiple uses.
llvm-svn: 96255
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
produce a table based matcher instead of gobs of C++ Code.
Though it's not done yet, the shrinkage seems promising,
the table for the X86 ISel is 75K and still has a lot of
optimization to come (compare to the ~1.5M of .o generated
the old way, much of which will go away).
The code is currently disabled by default (the #if 0 in
DAGISelEmitter.cpp). When enabled it generates a dead
SelectCode2 function in the DAGISel Header which will
eventually replace SelectCode.
There is still a lot of stuff left to do, which are
documented with a trail of FIXMEs.
llvm-svn: 96215
|
|
|
|
|
|
| |
This behaviour must be configurable.
llvm-svn: 96210
|
|
|
|
| |
llvm-svn: 96199
|
|
|
|
|
|
| |
on TreePatternNode to be methods on TreePatternNode.
llvm-svn: 96197
|
|
|
|
|
|
|
|
| |
that predated -fast-isel which attempted to speed up the dag pattern
matchers at -O0. Since fast-isel is around, this is basically
obsolete and removing it shrinks the generated dag isels.
llvm-svn: 96188
|
|
|
|
| |
llvm-svn: 96187
|
|
|
|
| |
llvm-svn: 96186
|
|
|
|
|
|
|
| |
Some tools do not like the '-option parameter' form. Should this be
configurable?
llvm-svn: 96130
|
|
|
|
|
|
| |
class out of line.
llvm-svn: 96113
|
|
|
|
|
|
| |
tables.
llvm-svn: 96073
|
|
|
|
| |
llvm-svn: 96065
|
|
|
|
|
|
| |
fix swapgs to be spelled right.
llvm-svn: 96058
|
|
|
|
|
|
| |
encoder and decoder by using new MRM_ forms.
llvm-svn: 96048
|
|
|
|
|
|
|
|
|
|
|
|
| |
whose opcodes extend into the ModR/M field using the
Form field of the instruction rather than by special
casing each instruction. Commented out the special
casing of VMCALL, which is the first instruction to use
this special form. While I was in the neighborhood,
added a few comments for people modifying the Intel
disassembler.
llvm-svn: 96043
|
|
|
|
|
|
|
| |
This will work better for the disassembler for modeling things
like lfence/monitor/vmcall etc.
llvm-svn: 95960
|
|
|
|
|
|
|
|
|
| |
matcher is now free of implicit operands!
- Still need to clean up the code now that we don't to worry about implicit
operands, and to make it a hard error if an instruction fails to specify all
of its operands for some reason.
llvm-svn: 95956
|
|
|
|
|
|
|
|
|
|
| |
testb %al, %al ## <MCInst #2412 TEST8rr
## <MCOperand Reg:2>
## <MCOperand Reg:2>>
jne LBB1_7 ## <MCInst #938 JNE_1
## <MCOperand Expr:(LBB1_7)>>
llvm-svn: 95935
|
|
|
|
| |
llvm-svn: 95808
|
|
|
|
|
|
| |
etc.)
llvm-svn: 95803
|
|
|
|
| |
llvm-svn: 95802
|
|
|
|
|
|
|
| |
- Pretty messy, but we need to rework how we handle tied operands in MCInst
anyway.
llvm-svn: 95774
|