| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 58946
|
| |
|
|
| |
llvm-svn: 58933
|
| |
|
|
|
|
| |
xs
llvm-svn: 58930
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 58929
|
| |
|
|
| |
llvm-svn: 58928
|
| |
|
|
|
|
|
|
| |
backend
and breaks llvm-gcc
llvm-svn: 58926
|
| |
|
|
|
|
| |
LLVMCellSPUCodeGen.
llvm-svn: 58925
|
| |
|
|
|
|
| |
clean start.
llvm-svn: 58924
|
| |
|
|
| |
llvm-svn: 58923
|
| |
|
|
|
|
| |
structure. Assembly printer now outputs the correct section for strings.
llvm-svn: 58921
|
| |
|
|
| |
llvm-svn: 58920
|
| |
|
|
|
|
|
| |
FIXME: it seems, that most of targets don't support
offsets wrt CPI/GlobalAddress', was it intentional?
llvm-svn: 58917
|
| |
|
|
| |
llvm-svn: 58908
|
| |
|
|
|
|
|
| |
variable for it. This greatly reduces amount of unused variables in
llvm2cpp-generated code
llvm-svn: 58905
|
| |
|
|
|
|
| |
size of stub.
llvm-svn: 58899
|
| |
|
|
| |
llvm-svn: 58898
|
| |
|
|
|
|
| |
ptr.
llvm-svn: 58897
|
| |
|
|
|
|
| |
are generated.
llvm-svn: 58896
|
| |
|
|
|
|
| |
these work on externsym machine relocations.
llvm-svn: 58895
|
| |
|
|
| |
llvm-svn: 58894
|
| |
|
|
| |
llvm-svn: 58893
|
| |
|
|
|
|
| |
theframe size is 0; the prologue and epilogue should be emitted in this case.
llvm-svn: 58890
|
| |
|
|
|
|
|
|
| |
promotion.
- Eliminate uses after free and simplify tests.
Devang: Please check that this is still doing what you intended.
llvm-svn: 58887
|
| |
|
|
| |
llvm-svn: 58883
|
| |
|
|
| |
llvm-svn: 58882
|
| |
|
|
| |
llvm-svn: 58877
|
| |
|
|
| |
llvm-svn: 58874
|
| |
|
|
| |
llvm-svn: 58872
|
| |
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 58871
|
| |
|
|
| |
llvm-svn: 58869
|
| |
|
|
| |
llvm-svn: 58868
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 58861
|
| |
|
|
|
|
|
|
|
| |
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.
llvm-svn: 58859
|
| |
|
|
| |
llvm-svn: 58856
|
| |
|
|
| |
llvm-svn: 58840
|
| |
|
|
| |
llvm-svn: 58839
|
| |
|
|
| |
llvm-svn: 58838
|
| |
|
|
| |
llvm-svn: 58836
|
| |
|
|
| |
llvm-svn: 58835
|
| |
|
|
|
| |
NB: This is likely to need more work.
llvm-svn: 58832
|
| |
|
|
| |
llvm-svn: 58830
|
| |
|
|
| |
llvm-svn: 58829
|
| |
|
|
| |
llvm-svn: 58828
|
| |
|
|
| |
llvm-svn: 58826
|
| |
|
|
|
|
|
|
|
| |
(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).
llvm-svn: 58825
|
| |
|
|
|
|
|
|
|
| |
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.
llvm-svn: 58824
|
| |
|
|
| |
llvm-svn: 58823
|
| |
|
|
| |
llvm-svn: 58822
|
| |
|
|
|
|
| |
when simplify a vector.
llvm-svn: 58820
|
| |
|
|
|
|
| |
in it, then emit stack protectors.
llvm-svn: 58819
|