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
