Previously, the code would scan the PHI nodes and build up a small
setvector of candidate value pairs in phi nodes to go and rewrite. Once
certain the rewrite could be performed, the code walks the set, and for
each one re-scans the entire PHI node list looking for nodes to rewrite
operands.
Instead, scan the PHI nodes once to check for hazards, and then scan it
a second time to rewrite the operands to selects. No set vector, and
a max of two scans.
The only downside is that we might form identical selects, but
instcombine or anything else should fold those easily, and it seems
unlikely to happen often.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173337 91177308-0d34-0410-b5e6-96231b3b80d8
pretty in doxygen, adding some of the details actually present in
a classic example where this matters (a loop from gzip and many other
compression algorithms), and a cautionary note about the risks inherent
in the transform. This has come up on the mailing lists recently, and
I suspect folks reading this code could benefit from going and looking
at the MI pass that can really deal with these issues.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173329 91177308-0d34-0410-b5e6-96231b3b80d8
Allow Mips16 routines to call Mips32 routines that have abi requirements
that either arguments or return values are passed in floating point
registers. This handles only the pic case. We have not done non pic
for Mips16 yet in any form.
The libm functions are Mips32, so with this addition we have a complete
Mips16 hard float implementation.
We still are not able to complete mix Mip16 and Mips32 with hard float.
That will be the next phase which will have several steps. For Mips32
to freely call Mips16 some stub functions must be created.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173320 91177308-0d34-0410-b5e6-96231b3b80d8
Allow schedulers to order DAG edges by critical path. This makes
DFS-based heuristics more stable and effective.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173317 91177308-0d34-0410-b5e6-96231b3b80d8
This is a helper class for the AttributeSetImpl class. It holds a set of
attributes that apply to a single element: function, return type, or
parameter.
These are uniqued.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173310 91177308-0d34-0410-b5e6-96231b3b80d8
This does the right thing unless the multiplication overflows, but the old code
didn't handle that case either.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173276 91177308-0d34-0410-b5e6-96231b3b80d8
This is still an egregious hack since we don't have a nice interface for this
kind of thing but should help the valgrind leak check buildbot to become green.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173267 91177308-0d34-0410-b5e6-96231b3b80d8
used uninitialized, since it fails to understand that Array is only used when
SingleValue is not, and outputs a warning. It also seems generally safer given
that the constructor is non-trivial and has plenty of early exits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173242 91177308-0d34-0410-b5e6-96231b3b80d8
The requirements of the strong heuristic are:
* A Protector is required for functions which contain an array, regardless of
type or length.
* A Protector is required for functions which contain a structure/union which
contains an array, regardless of type or length. Note, there is no limit to
the depth of nesting.
* A protector is required when the address of a local variable (i.e., stack
based variable) is exposed. (E.g., such as through a local whose address is
taken as part of the RHS of an assignment or a local whose address is taken as
part of a function argument.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173231 91177308-0d34-0410-b5e6-96231b3b80d8
SSPStrong applies a heuristic to insert stack protectors in these situations:
* A Protector is required for functions which contain an array, regardless of
type or length.
* A Protector is required for functions which contain a structure/union which
contains an array, regardless of type or length. Note, there is no limit to
the depth of nesting.
* A protector is required when the address of a local variable (i.e., stack
based variable) is exposed. (E.g., such as through a local whose address is
taken as part of the RHS of an assignment or a local whose address is taken as
part of a function argument.)
This patch implements the SSPString attribute to be equivalent to
SSPRequired. This will change in a subsequent patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173230 91177308-0d34-0410-b5e6-96231b3b80d8
Collections of attributes are handled via the AttributeSet class now. This
finally frees us up to make significant changes to how attributes are structured.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173228 91177308-0d34-0410-b5e6-96231b3b80d8
Remove Cxxx registers, add new special register - "ALU_CONST" and new
operand for each alu src - "sel". ALU_CONST is used to designate that the
new operand contains the value to override src.sel, src.kc_bank, src.chan
for constants in the driver.
Patch by: Vadim Girlin
Vincent Lejeune:
- Use pointers for constants
- Fold CONST_ADDRESS when possible
Tom Stellard:
- Give CONSTANT_BUFFER_0 its own address space
- Use integer types for constant loads
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173222 91177308-0d34-0410-b5e6-96231b3b80d8
The method PerformCodePlacement was doing too much (i.e. 3x loops, lots of
different checking). This refactoring separates the analysis section of the
method into a separate function while leaving the actual code placement and
analysis preparation in PerformCodePlacement.
*NOTE* Really this part of ObjCARC should be refactored out of the main pass
class into its own seperate class/struct. But, it is not time to make that
change yet though (don't want to make such an invasive change without fixing all
of the bugs first).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173201 91177308-0d34-0410-b5e6-96231b3b80d8
- Add list of physical registers clobbered in pseudo atomic insts
Physical registers are clobbered when pseudo atomic instructions are
expanded. Add them in clobber list to prevent DAG scheduler to
mis-schedule them after these insns are declared side-effect free.
- Add test case from Michael Kuperstein <michael.m.kuperstein@intel.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173200 91177308-0d34-0410-b5e6-96231b3b80d8
the body does not use them and it appears the body has positional parameters.
This can cause unexpected results as in the added test case. As the darwin
version of gas(1) which only supported positional parameters, happened to
ignore the named parameters. Now that we want to support both styles of
macros we issue a warning in this specific case.
rdar://12861644
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173199 91177308-0d34-0410-b5e6-96231b3b80d8
Use the AttributeSet when we're talking about more than one attribute. Add a
function that adds a single attribute. No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173196 91177308-0d34-0410-b5e6-96231b3b80d8
an expression. Currently this bug causes the line to be ignored in a
release build and an assert in a debug build.
rdar://13062484
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173195 91177308-0d34-0410-b5e6-96231b3b80d8
