support targets that support these conversions. Users should avoid using
this node as the current targets don't generating code for it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59001 91177308-0d34-0410-b5e6-96231b3b80d8
where the argument is an apint, or smaller than the minimum
size for which there is a libcall (i32).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58994 91177308-0d34-0410-b5e6-96231b3b80d8
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
The previous patches didn't match correctly. Also, we need to make sure that
the conditional is the same before doing the transformation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58978 91177308-0d34-0410-b5e6-96231b3b80d8
implementation detail of DIFactory anyway, and this allows it to avoid
recomputing the same type over and over.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58960 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
information. This logically replaces the "Desc" classes in
MachineModuleInfo. Nice features of these classes are that they:
1. Are much more efficient than MMI because they don't create a
temporary parallel data structure for debug info that has to be
'serialized' and 'deserialized' into/out of the module.
2. These provide a much cleaner abstraction for debug info than
MMI, which will make it easier to change the implementation in
the future (to be MDNode-based).
3. These are much easier to use than the MMI interfaces, requiring
a lot less code in the front-ends.
4. These can be used to both create (for frontends) and read (for
codegen) debug information. DebugInfoBuilder can only be used
to create the nodes.
So far, this is implemented just enough to support the debug info
generation needs of clang. This can and should be extended to
support the full set of debug info constructs, and we should switch
llvm-gcc and llc over to using this in the near future.
This code also has a ton of FIXMEs in it, because the way we
currently represent debug info in LLVM IR is basically insane in a
variety of details. This sort of issue should be fixed when we
eventually reimplement debug info on top of MDNodes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58954 91177308-0d34-0410-b5e6-96231b3b80d8
original code was matching like this:
if (match(A, m_Not(m_Value(B))))
B was already matched as a 'select' instruction. However, this isn't matching
what we think it's matching. It would match B as a 'Value', so basically
anything would match to it. In this case, a Constant matched. B was replaced
with a constant representation. And then the wrong value would be used in the
SelectInst::Create statement, causing a crash.
After thinking on this for a moment, and after Nick L. told me how the pattern
matching stuff was supposed to work, the solution was to match NOT an m_Value,
but an m_Select.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58946 91177308-0d34-0410-b5e6-96231b3b80d8
to generate signed ICMP instructions to replace the FCMP. This would violate
the following:
define i1 @test1(i32 %val) {
%1 = uitofp i32 %val to double
%2 = fcmp ole double %1, 0.000000e+00
ret i1 %2
}
would be transformed into:
define i1 @test1(i32 %val) {
%1 = icmp slt i33 %val, 1
ret i1 %1
}
which is obviously wrong. This patch modifes InstCombiner::FoldFCmp_IntToFP_Cst
to handle when the LHS comes from UIToFP.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58929 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
promotion.
- Eliminate uses after free and simplify tests.
Devang: Please check that this is still doing what you intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58887 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
This is a temporary fix for the -print-emitted-asm option, where
errs() is used as the stream, in the case where other code is
using stderr without using errs()' buffer. Hopefully soon we'll
fix errs() to be non-buffered instead. Patch by Preston Gurd.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58859 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
