the key. This will cause it to create a new std::string, which isn't
wanted. Instead, pass back the "const char*". Modify the EmitString() method to
take a "const char*".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@68741 91177308-0d34-0410-b5e6-96231b3b80d8
register destinations that are tied to source operands. The
TargetInstrDescr::findTiedToSrcOperand method silently fails for inline
assembly. The existing MachineInstr::isRegReDefinedByTwoAddr was very
close to doing what is needed, so this revision makes a few changes to
that method and also renames it to isRegTiedToUseOperand (for consistency
with the very similar isRegTiedToDefOperand and because it handles both
two-address instructions and inline assembly with tied registers).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@68714 91177308-0d34-0410-b5e6-96231b3b80d8
with SUBREG_TO_REG, teach SimpleRegisterCoalescing to coalesce
SUBREG_TO_REG instructions (which are similar to INSERT_SUBREG
instructions), and teach the DAGCombiner to take advantage of this on
targets which support it. This eliminates many redundant
zero-extension operations on x86-64.
This adds a new TargetLowering hook, isZExtFree. It's similar to
isTruncateFree, except it only applies to actual definitions, and not
no-op truncates which may not zero the high bits.
Also, this adds a new optimization to SimplifyDemandedBits: transform
operations like x+y into (zext (add (trunc x), (trunc y))) on targets
where all the casts are no-ops. In contexts where the high part of the
add is explicitly masked off, this allows the mask operation to be
eliminated. Fix the DAGCombiner to avoid undoing these transformations
to eliminate casts on targets where the casts are no-ops.
Also, this adds a new two-address lowering heuristic. Since
two-address lowering runs before coalescing, it helps to be able to
look through copies when deciding whether commuting and/or
three-address conversion are profitable.
Also, fix a bug in LiveInterval::MergeInClobberRanges. It didn't handle
the case that a clobber range extended both before and beyond an
existing live range. In that case, multiple live ranges need to be
added. This was exposed by the new subreg coalescing code.
Remove 2008-05-06-SpillerBug.ll. It was bugpoint-reduced, and the
spiller behavior it was looking for no longer occurrs with the new
instruction selection.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@68576 91177308-0d34-0410-b5e6-96231b3b80d8
When compiling in Thumb mode, only the low (R0-R7) registers are available
for most instructions. Breaking the low registers into a new register class
handles this. Uses of R12, SP, etc, are handled explicitly where needed
with copies inserted to move results into low registers where the rest of
the code generator can deal with them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@68545 91177308-0d34-0410-b5e6-96231b3b80d8
elements in a form that is efficient for the reader to just get a
pointer in memory and start reading. APIs to do efficient reading
and writing are still todo.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@68465 91177308-0d34-0410-b5e6-96231b3b80d8
Constant, MDString and MDNode which can only be used by globals with a name
that starts with "llvm." or as arguments to a function with the same naming
restriction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@68420 91177308-0d34-0410-b5e6-96231b3b80d8
- Particularly nice for small constant strings, which get optimized
down nicely. On a synthetic benchmark writing out "hello" in a
loop, this is about 2x faster with gcc and 3x faster with
llvm-gcc. llc on insn-attrtab.bc from 403.gcc is about .5% faster.
- I tried for a fancier solution which wouldn't increase code size as
much (by trying to match constant arrays), but can't quite make it
fly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@68396 91177308-0d34-0410-b5e6-96231b3b80d8
Note that these are distinct from TargetInstrInfo::INSERT_SUBREG
and TargetInstrInfo::EXTRACT_SUBREG, which are used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@68355 91177308-0d34-0410-b5e6-96231b3b80d8
"The code was doing "if (End+NumInputs > Capacity) ...". If End is
close to 0xFFFFFFFF and NumInputs is large, it'll overflow, the
condition will come out false, and the vector won't grow to
accommodate the new elements, and the program will crash in memmove."
Patch by Jeffrey Yasskin!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@68277 91177308-0d34-0410-b5e6-96231b3b80d8
- The code is silly, I'm just amusing myself. Rewrite to be efficient
if you like. :)
Also, if you wish to debate the proper names of the triple components
I'm all ears.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@68252 91177308-0d34-0410-b5e6-96231b3b80d8
is appropriate. This helps visually differentiate host-oriented
calculations from target-oriented calculations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@68227 91177308-0d34-0410-b5e6-96231b3b80d8
