Age | Commit message (Collapse) | Author |
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146186 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
computation to determine whether the block dominates all uses or not.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146184 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
SDNodes. Mark these nodes as illegal by default, unless the target declares otherwise.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146171 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
clients to decide whether to look inside bundled instructions and whether
the query should return true if any / all bundled instructions have the
queried property.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146168 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
We must not issue a bitcast operation for integer-promotion of vector types, because the
location of the values in the vector may be different.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146150 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146136 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
<rdar://problem/10460321>. No testcase because this is very sensitive to scheduling.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146087 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
it's rather delicate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146083 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
that he isn't using these any more, so just delete them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146076 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Skip two looking up at BlockChain.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146053 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
generator to it. For non-bundle instructions, these behave exactly the same
as the MC layer API.
For properties like mayLoad / mayStore, look into the bundle and if any of the
bundled instructions has the property it would return true.
For properties like isPredicable, only return true if *all* of the bundled
instructions have the property.
For properties like canFoldAsLoad, isCompare, conservatively return false for
bundles.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146026 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
doesn't affect any in-tree target.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146015 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146004 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146001 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This flag is used when bundling machine instructions. It indicates
whether the operand reads a value defined inside or outside its bundle.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145997 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
correctly. PR11494.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145996 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145995 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- Remove unused types/fields.
- Add some constantness.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145993 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
1. Added opcode BUNDLE
2. Taught MachineInstr class to deal with bundled MIs
3. Changed MachineBasicBlock iterator to skip over bundled MIs; added an iterator to walk all the MIs
4. Taught MachineBasicBlock methods about bundled MIs
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145975 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145965 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145944 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145943 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145903 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The new register allocator is much more able to split back up ranges too constrained by register classes.
Fixes <rdar://problem/10466609>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145899 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145897 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145893 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This was actually a bit of a mess. TLI.setPrefLoopAlignment was clearly
documented as taking log2(bytes) units, but the x86 target would still
set a preferred loop alignment of '16'.
CodePlacementOpt passed this number on to the basic block, and
AsmPrinter interpreted it as bytes.
Now both MachineFunction and MachineBasicBlock use logarithmic
alignments.
Obviously, MachineConstantPool still measures alignments in bytes, so we
can emulate the thrill of using as.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145889 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145801 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
not get there any other way.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145789 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Maybe some targets should use this as well.
Patch by Evgeniy Stepanov!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145781 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
-3% on ARMDissasembler.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145773 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
change, now you need a TargetOptions object to create a TargetMachine. Clang
patch to follow.
One small functionality change in PTX. PTX had commented out the machine
verifier parts in their copy of printAndVerify. That now calls the version in
LLVMTargetMachine. Users of PTX who need verification disabled should rely on
not passing the command-line flag to enable it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145714 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
instruction in Sequence is a Noop
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145677 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Missing file from r145629.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145634 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145629 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
attempt.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145425 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145420 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
non_lazy_symbol_pointers section (__IMPORT,__pointers). Ignore the 'hidden' part
since that will place it in the wrong section.
<rdar://problem/10443720>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145356 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
duplicating the logic for globals. Make llvm::ComputeMaskedBits handle GlobalVariables slightly more aggressively, to match what InferPtrAlignment knew how to do.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145304 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Conservatively returns zero when the GV does not specify an alignment nor is it
initialized. Previously it returns ABI alignment for type of the GV. However, if
the type is a "packed" type, then the under-specified alignments is attached to
the load / store instructions. In that case, the alignment of the type cannot be
trusted.
rdar://10464621
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145300 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
than ABI alignment. These are loads / stores from / to "packed" data structures.
Their alignments are intentionally under-specified.
rdar://10301431
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145273 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145267 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145263 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
fallthrough) in cases where we might fail to rotate an exit to an outer
loop onto the end of the loop chain.
Having *some* rotation, but not performing this rotation, is the primary
fix of thep performance regression with -enable-block-placement for
Olden/em3d (a whopping 30% regression). Still working on reducing the
test case that actually exercises this and the new rotation strategy out
of this code, but I want to check if this regresses other test cases
first as that may indicate it isn't the correct fix.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145195 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
was centered around the premise of laying out a loop in a chain, and
then rotating that chain. This is good for preserving contiguous layout,
but bad for actually making sane rotations. In order to keep it safe,
I had to essentially make it impossible to rotate deeply nested loops.
The information needed to correctly reason about a deeply nested loop is
actually available -- *before* we layout the loop. We know the inner
loops are already fused into chains, etc. We lose information the moment
we actually lay out the loop.
The solution was the other alternative for this algorithm I discussed
with Benjamin and some others: rather than rotating the loop
after-the-fact, try to pick a profitable starting block for the loop's
layout, and then use our existing layout logic. I was worried about the
complexity of this "pick" step, but it turns out such complexity is
needed to handle all the important cases I keep teasing out of benchmarks.
This is, I'm afraid, a bit of a work-in-progress. It is still
misbehaving on some likely important cases I'm investigating in Olden.
It also isn't really tested. I'm going to try to craft some interesting
nested-loop test cases, but it's likely to be extremely time consuming
and I don't want to go there until I'm sure I'm testing the correct
behavior. Sadly I can't come up with a way of getting simple, fine
grained test cases for this logic. We need complex loop structures to
even trigger much of it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145183 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145181 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
heavily on AnalyzeBranch. That routine doesn't behave as we want given
that rotation occurs mid-way through re-ordering the function. Instead
merely check that there are not unanalyzable branching constructs
present, and then reason about the CFG via successor lists. This
actually simplifies my mental model for all of this as well.
The concrete result is that we now will rotate more loop chains. I've
added a test case from Olden highlighting the effect. There is still
a bit more to do here though in order to regain all of the performance
in Olden.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145179 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
pass. This is designed to achieve one of the important optimizations
that the old code placement pass did, but more simply.
This is a somewhat rough and *very* conservative version of the
transform. We could get a lot fancier here if there are profitable cases
to do so. In particular, this only looks for a single pattern, it
insists that the loop backedge being rotated away is the last backedge
in the chain, and it doesn't provide any means of doing better in-loop
placement due to the rotation. However, it appears that it will handle
the important loops I am finding in the LLVM test suite.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145158 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145154 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
need lots of fanciness around retaining a reference to a Chain's slot in
the BlockToChain map, but that's all gone now. We can just go directly
to allocating the new chain (which will update the mapping for us) and
using it.
Somewhat gross mechanically generated test case replicates the issue
Duncan spotted when actually testing this out.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145120 91177308-0d34-0410-b5e6-96231b3b80d8
|