inform the optimizers that the result must be zero/
sign extended from the smaller type. For example,
if a fp to unsigned i16 is promoted to fp to i32,
then we are allowed to assume that the extra 16 bits
are zero (because the result of fp to i16 is undefined
if the result does not fit in an i16). This is
quite aggressive, but should help the optimizers
produce better code. This requires correcting a
test which thought that fp_to_uint is some kind
of truncation, which it is not: in the testcase
(which does fp to i1), either the fp value converts
to 0 or 1 or the result is undefined, which is
quite different to truncation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58991 91177308-0d34-0410-b5e6-96231b3b80d8
an array that is empty. Instead of requiring this array, allow a null pointer.
This shrinks all forward references of structs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58959 91177308-0d34-0410-b5e6-96231b3b80d8
FIXME: it seems, that most of targets don't support
offsets wrt CPI/GlobalAddress', was it intentional?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58917 91177308-0d34-0410-b5e6-96231b3b80d8
This is Chris' patch from the PR, modified to realize that
SETUGT/SETULT occur legitimately with integers, plus
two fixes in LegalizeDAG to pass a valid result type into
LegalizeSetCC. The argument of TLI.getSetCCResultType is
ignored on PPC, but I think I'm following usage elsewhere.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58871 91177308-0d34-0410-b5e6-96231b3b80d8
the condition for a BRCOND, according to what is
returned by getSetCCResultContents. Since all
targets return the same thing (ZeroOrOneSetCCResult),
this should be harmless! The point is that all over
the place the result of SETCC is fed directly into
BRCOND. On machines for which getSetCCResultContents
returns ZeroOrNegativeOneSetCCResult, this is a
sign-extended boolean. So it seems dangerous to
also feed BRCOND zero-extended booleans in some
circumstances - for example, when promoting the
condition.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58861 91177308-0d34-0410-b5e6-96231b3b80d8
(e.g. a bitfield test) narrow the load as much as possible.
The has the potential to avoid unnecessary partial-word
load-after-store conflicts, which cause stalls on several targets.
Also a size win on x86 (testb vs testl).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58825 91177308-0d34-0410-b5e6-96231b3b80d8
LLVM IR code and not in the selection DAG ISel. This is a cleaner solution.
- Fix the heuristic for determining if protectors are necessary. The previous
one wasn't checking the proper type size.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58824 91177308-0d34-0410-b5e6-96231b3b80d8
- Get rid of "HasStackProtector" in MachineFrameInfo.
- Modify intrinsics to tell which are doing what with memory.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58799 91177308-0d34-0410-b5e6-96231b3b80d8
- stackprotector_prologue creates a stack object and stores the guard there.
- stackprotector_epilogue reads the stack guard from the stack position created
by stackprotector_prologue.
- The PrologEpilogInserter was changed to make sure that the stack guard is
first on the stack frame.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58791 91177308-0d34-0410-b5e6-96231b3b80d8
"getOrInsertFunction" in that it either adds a new declaration of the global
and returns it, or returns the current one -- optionally casting it to the
correct type.
- Use the new getOrInsertGlobal in the stack protector code.
- Use "splitBasicBlock" in the stack protector code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58727 91177308-0d34-0410-b5e6-96231b3b80d8
- Use enums instead of magic numbers.
- Rework algorithm to use the bytes size from the target to determine when to
emit stack protectors.
- Get rid of "propolice" in any comments.
- Renamed an option to its expanded form.
- Other miscellanenous changes.
More changes will come after this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58723 91177308-0d34-0410-b5e6-96231b3b80d8
* The prologue is modified to read the __stack_chk_guard global and insert it
onto the stack.
* The epilogue is modified to read the stored guard from the stack and compare
it to the original __stack_chk_guard value. If they differ, then the
__stack_chk_fail() function is called.
* The stack protector needs to be first on the stack (after the parameters) to
catch any stack-smashing activities.
Front-end support will follow after a round of beta testing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58673 91177308-0d34-0410-b5e6-96231b3b80d8
sized integers like i129, and also reduce the number
of assumptions made about how vaarg is implemented.
This still doesn't work correctly for small integers
like (eg) i1 on x86, since x86 passes each of them
(essentially an i8) in a 4 byte stack slot, so the
pointer needs to be advanced by 4 bytes not by 1 byte
as now. But this is no longer a LegalizeTypes problem
(it was also wrong in LT before): it is a bug in the
operation expansion in LegalizeDAG: now LegalizeTypes
turns an i1 vaarg into an i8 vaarg which would work
fine if only the i8 vaarg was turned into correct code
later.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58635 91177308-0d34-0410-b5e6-96231b3b80d8
