| Age | Commit message (Collapse) | Author |
|---|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163886 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163885 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the injected class name of a dependent base class here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163884 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is essentially a ground up re-think of the SROA pass in LLVM. It
was initially inspired by a few problems with the existing pass:
- It is subject to the bane of my existence in optimizations: arbitrary
thresholds.
- It is overly conservative about which constructs can be split and
promoted.
- The vector value replacement aspect is separated from the splitting
logic, missing many opportunities where splitting and vector value
formation can work together.
- The splitting is entirely based around the underlying type of the
alloca, despite this type often having little to do with the reality
of how that memory is used. This is especially prevelant with unions
and base classes where we tail-pack derived members.
- When splitting fails (often due to the thresholds), the vector value
replacement (again because it is separate) can kick in for
preposterous cases where we simply should have split the value. This
results in forming i1024 and i2048 integer "bit vectors" that
tremendously slow down subsequnet IR optimizations (due to large
APInts) and impede the backend's lowering.
The new design takes an approach that fundamentally is not susceptible
to many of these problems. It is the result of a discusison between
myself and Duncan Sands over IRC about how to premptively avoid these
types of problems and how to do SROA in a more principled way. Since
then, it has evolved and grown, but this remains an important aspect: it
fixes real world problems with the SROA process today.
First, the transform of SROA actually has little to do with replacement.
It has more to do with splitting. The goal is to take an aggregate
alloca and form a composition of scalar allocas which can replace it and
will be most suitable to the eventual replacement by scalar SSA values.
The actual replacement is performed by mem2reg (and in the future
SSAUpdater).
The splitting is divided into four phases. The first phase is an
analysis of the uses of the alloca. This phase recursively walks uses,
building up a dense datastructure representing the ranges of the
alloca's memory actually used and checking for uses which inhibit any
aspects of the transform such as the escape of a pointer.
Once we have a mapping of the ranges of the alloca used by individual
operations, we compute a partitioning of the used ranges. Some uses are
inherently splittable (such as memcpy and memset), while scalar uses are
not splittable. The goal is to build a partitioning that has the minimum
number of splits while placing each unsplittable use in its own
partition. Overlapping unsplittable uses belong to the same partition.
This is the target split of the aggregate alloca, and it maximizes the
number of scalar accesses which become accesses to their own alloca and
candidates for promotion.
Third, we re-walk the uses of the alloca and assign each specific memory
access to all the partitions touched so that we have dense use-lists for
each partition.
Finally, we build a new, smaller alloca for each partition and rewrite
each use of that partition to use the new alloca. During this phase the
pass will also work very hard to transform uses of an alloca into a form
suitable for promotion, including forming vector operations, speculating
loads throguh PHI nodes and selects, etc.
After splitting is complete, each newly refined alloca that is
a candidate for promotion to a scalar SSA value is run through mem2reg.
There are lots of reasonably detailed comments in the source code about
the design and algorithms, and I'm going to be trying to improve them in
subsequent commits to ensure this is well documented, as the new pass is
in many ways more complex than the old one.
Some of this is still a WIP, but the current state is reasonbly stable.
It has passed bootstrap, the nightly test suite, and Duncan has run it
successfully through the ACATS and DragonEgg test suites. That said, it
remains behind a default-off flag until the last few pieces are in
place, and full testing can be done.
Specific areas I'm looking at next:
- Improved comments and some code cleanup from reviews.
- SSAUpdater and enabling this pass inside the CGSCC pass manager.
- Some datastructure tuning and compile-time measurements.
- More aggressive FCA splitting and vector formation.
Many thanks to Duncan Sands for the thorough final review, as well as
Benjamin Kramer for lots of review during the process of writing this
pass, and Daniel Berlin for reviewing the data structures and algorithms
and general theory of the pass. Also, several other people on IRC, over
lunch tables, etc for lots of feedback and advice.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163883 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163882 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
1. Add MoveR3216
2. Correct spelling for Move32R16
Patch by Reed Kotler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163869 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
umulo legalization.
Fixes PR13839
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163856 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
closer to where they're needed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163855 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
For gas compatibility.
rdar://12219394
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163854 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
.set a, b - c + CONSTANT
d = b - c + CONSTANT
Both 'a' and 'd' should be marked as absolute symbols (N_ABS).
rdar://12219394
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163853 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
loads and stores.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163844 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
mapSectionAddress() wasn't consistent.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163843 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163835 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- Enhance the fix to PR12312 to support wider integer, such as 256-bit
integer. If more than 1 fully evaluated vectors are found, POR them
first followed by the final PTEST.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163832 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- Find a legal vector type before casting and extracting element from it.
- As the new vector type may have more than 2 elements, build the final
hi/lo pair by BFS pairing them from bottom to top.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163830 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Add a PatFrag to match X86tcret using 6 fixed registers or less. This
avoids folding loads into TCRETURNmi64 using 7 or more volatile
registers.
<rdar://problem/12282281>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163819 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163817 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163815 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
immediate operands to be copied.
Patch by Reed Kotler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163811 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The patch caused "Wrong topological sorting" assertions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163810 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
account.
This is common when storing to global variables.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163809 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163808 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
bugs in user code or in the compiler. Also, dont assert if the protection is not enabled.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163807 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
reduce code duplication.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163805 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163803 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
bitcast of fneg to integers
by xoring the high-bit. This fails if the source operand is a vector because we need to negate
each of the elements in the vector.
Fix rdar://12281066 PR13813.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163802 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163801 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
which requires TargetData.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163799 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
are within the lifetime zone. Sometime legitimate usages of allocas are
hoisted outside of the lifetime zone. For example, GEPS may calculate the
address of a member of an allocated struct. This commit makes sure that
we only check (abort regions or assert) for instructions that read and write
memory using stack frames directly. Notice that by allowing legitimate
usages outside the lifetime zone we also stop checking for instructions
which use derivatives of allocas. We will catch less bugs in user code
and in the compiler itself.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163791 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
* 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).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163790 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163774 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The assumption that the target address for the relocation will always be
sizeof(intptr_t) and will always contain an addend for the relocation
value is very wrong. Default to no addend for now.
rdar://12157052
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163765 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
When comparing to the macho relocation type enum value, make sure we're only
comparing against the bits in the RelType that correspond.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163764 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163763 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
We don't have enough GR64_TC registers when calling a varargs function
with 6 arguments. Since %al holds the number of vector registers used,
only %r11 is available as a scratch register.
This means that addressing modes using both base and index registers
can't be folded into TCRETURNmi64.
<rdar://problem/12282281>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163761 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This function writes out the current values of the counters and then resets
them. This can be used similarly to the __gcov_flush function to sync the
counters when need be. For instance, in a situation where the application
doesn't exit.
<rdar://problem/12185886>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163757 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Add some support for dealing with an object pointer on arguments.
Part of rdar://9797999
which now supports adding the object pointer attribute to the
subprogram as it should.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163754 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
1. Remove RA from list of allocatable registers
2. Enable d,y,r constraint inline assembly instructions
Patch by Reed Kotler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163753 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- BlockAddress has no support of BA + offset form and there is no way to
propagate that offset into machine operand;
- Add BA + offset support and a new interface 'getTargetBlockAddress' to
simplify target block address forming;
- All targets are modified to use new interface and X86 backend is enhanced to
support BA + offset addressing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163743 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163739 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
already knows how to handle the case where DstRC was NULL, so it's not actually protecting us from anything, and this pattern can come up when using unknown_class operands in the SelectionDAG.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163736 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163735 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This should be done on the subprogram, not the variable itself.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163734 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163729 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to the default target.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163724 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163721 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
was fixed in r163713.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163715 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
nonvolatile condition register fields across calls under the SVR4 ABIs.
* With the 64-bit ABI, the save location is at a fixed offset of 8 from
the stack pointer. The frame pointer cannot be used to access this
portion of the stack frame since the distance from the frame pointer may
change with alloca calls.
* With the 32-bit ABI, the save location is just below the general
register save area, and is accessed via the frame pointer like the rest
of the save areas. This is an optional slot, so it must only be created
if any of CR2, CR3, and CR4 were modified.
* For both ABIs, save/restore logic is generated only if one of the
nonvolatile CR fields were modified.
I also took this opportunity to clean up an extra FIXME in
PPCFrameLowering.h. Save area offsets for 32-bit GPRs are meaningless
for the 64-bit ABI, so I removed them for correctness and efficiency.
Fixes PR13708 and partially also PR13623. It lets us enable exception handling
on PPC64.
Patch by William J. Schmidt!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163713 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163710 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
behaviour (converting NaN values between float and double).
SelectionDAG::getConstantFP(double Val, EVT VT, bool isTarget);
should not be used when Val is not a simple constant (as the comment in
SelectionDAG.h indicates). This patch avoids using this function
when folding an unknown constant through a bitcast, where it cannot be
guaranteed that Val will be a simple constant.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163703 91177308-0d34-0410-b5e6-96231b3b80d8
|
