it with memcpy. This also fixes a problem on big-endian hosts, where
addUnaligned would return different results depending on the alignment
of the data.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151247 91177308-0d34-0410-b5e6-96231b3b80d8
Added array subscript to SparseSet for convenience.
Slight reorg to make it easier to manage the def/use sets.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151228 91177308-0d34-0410-b5e6-96231b3b80d8
value is zero. Instead of a cmov + op, issue an conditional op instead. e.g.
cmp r9, r4
mov r4, #0
moveq r4, #1
orr lr, lr, r4
should be:
cmp r9, r4
orreq lr, lr, #1
That is, optimize (or x, (cmov 0, y, cond)) to (or.cond x, y). Similarly extend
this to xor as well as (and x, (cmov -1, y, cond)) => (and.cond x, y).
It's possible to extend this to ADD and SUB but I don't think they are common.
rdar://8659097
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151224 91177308-0d34-0410-b5e6-96231b3b80d8
The standard function epilog includes a .size directive, but ppc64 uses
an alternate local symbol to tag the actual start of each function.
Until recently, binutils accepted the .size directive as:
.size test1, .Ltmp0-test1
however, using this directive with recent binutils will result in the error:
.size expression for XXX does not evaluate to a constant
so we must use the label which actually tags the start of the function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151200 91177308-0d34-0410-b5e6-96231b3b80d8
Add some data structures to represent for loops. These will be
referenced during object processing to do any needed iteration and
instantiation.
Add foreach keyword support to the lexer.
Add a mode to indicate that we're parsing a foreach loop. This allows
the value parser to early-out when processing the foreach value list.
Add a routine to parse foreach iteration declarations. This is
separate from ParseDeclaration because the type of the named value
(the iterator) doesn't match the type of the initializer value (the
value list). It also needs to add two values to the foreach record:
the iterator and the value list.
Add parsing support for foreach.
Add the code to process foreach loops and create defs based
on iterator values.
Allow foreach loops to be matched at the top level.
When parsing an IDValue check if it is a foreach loop iterator for one
of the active loops. If so, return a VarInit for it.
Add Emacs keyword support for foreach.
Add VIM keyword support for foreach.
Add tests to check foreach operation.
Add TableGen documentation for foreach.
Support foreach with multiple objects.
Support non-braced foreach body with one object.
Do not require types for the foreach declaration. Assume the iterator
type from the iteration list element type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151164 91177308-0d34-0410-b5e6-96231b3b80d8
chip in r139383, and the PSP components of the triple are really
annoying to parse. Let's leave this chapter behind. There is no reason
to expect LLVM to see a PSP-related triple these days, and so no
reasonable motivation to support them.
It might be reasonable to prune a few of the older MIPS triple forms in
general, but as those at least cause no burden on parsing (they aren't
both a chip and an OS!), I'm happy to leave them in for now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151156 91177308-0d34-0410-b5e6-96231b3b80d8
The vast majority of virtual register definitions don't need an entry
in the DAG builder's VRegDefs set.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151136 91177308-0d34-0410-b5e6-96231b3b80d8
Affect on SD scheduling and postRA scheduling:
Printing the DAG will display the nodes in top-down topological order.
This matches the order within the MBB and makes my life much easier in general.
Affect on misched:
We don't need to track virtual register uses at all. This is awesome.
I also intend to rely on the SUnit ID as a topo-sort index. So if A < B then we cannot have an edge B -> A.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151135 91177308-0d34-0410-b5e6-96231b3b80d8
the dominance once the dominates method is fixed and why we can use the builder's
insertion point.
Fixes pr12048.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151125 91177308-0d34-0410-b5e6-96231b3b80d8
This makes RAFast 4% faster, and it gets rid of the dodgy DenseMap
iteration.
This also revealed that RAFast would sometimes dereference DenseMap
iterators after erasing other elements from the map. That does seem to
work in the current DenseMap implementation, but SparseSet doesn't allow
it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151111 91177308-0d34-0410-b5e6-96231b3b80d8
For objects that can be identified by small unsigned keys, SparseSet
provides constant time clear() and fast deterministic iteration. Insert,
erase, and find operations are typically faster than hash tables.
SparseSet is useful for keeping information about physical registers,
virtual registers, or numbered basic blocks.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151110 91177308-0d34-0410-b5e6-96231b3b80d8
This test case was way too strict, matching the entire assembly output.
Every non-trivial change to the ppc backend or -O0 pipeline required
the test to be updated.
It should be replaced with a test of the specific vaarg feature.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151105 91177308-0d34-0410-b5e6-96231b3b80d8
