mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-23 19:23:23 +01:00
e2892c0c04
I might have called this "r246507, the sequel". It fixes the same issue, as the
issue has cropped up in a few more places. The underlying problem is that
isSetCCEquivalent can pick up select_cc nodes with a result type that is not
legal for a setcc node to have, and if we use that type to create new setcc
nodes, nothing fixes that (and so we've violated the contract that the
infrastructure has with the backend regarding setcc node types).
Fixes PR30276.
For convenience, here's the commit message from r246507, which explains the
problem is greater detail:
[DAGCombine] Fixup SETCC legality checking
SETCC is one of those special node types for which operation actions (legality,
etc.) is keyed off of an operand type, not the node's value type. This makes
sense because the value type of a legal SETCC node is determined by its
operands' value type (via the TLI function getSetCCResultType). When the
SDAGBuilder creates SETCC nodes, it either creates them with an MVT::i1 value
type, or directly with the value type provided by TLI.getSetCCResultType.
The first problem being fixed here is that DAGCombine had several places
querying TLI.isOperationLegal on SETCC, but providing the return of
getSetCCResultType, instead of the operand type directly. This does not mean
what the author thought, and "luckily", most in-tree targets have SETCC with
Custom lowering, instead of marking them Legal, so these checks return false
anyway.
The second problem being fixed here is that two of the DAGCombines could create
SETCC nodes with arbitrary (integer) value types; specifically, those that
would simplify:
(setcc a, b, op1) and|or (setcc a, b, op2) -> setcc a, b, op3
(which is possible for some combinations of (op1, op2))
If the operands of the and|or node are actual setcc nodes, then this is not an
issue (because the and|or must share the same type), but, the relevant code in
DAGCombiner::visitANDLike and DAGCombiner::visitORLike actually calls
DAGCombiner::isSetCCEquivalent on each operand, and that function will
recognise setcc-like select_cc nodes with other return types. And, thus, when
creating new SETCC nodes, we need to be careful to respect the value-type
constraint. This is even true before type legalization, because it is quite
possible for the SELECT_CC node to have a legal type that does not happen to
match the corresponding TLI.getSetCCResultType type.
To be explicit, there is nothing that later fixes the value types of SETCC
nodes (if the type is legal, but does not happen to match
TLI.getSetCCResultType). Creating SETCCs with an MVT::i1 value type seems to
work only because, either MVT::i1 is not legal, or it is what
TLI.getSetCCResultType returns if it is legal. Fixing that is a larger change,
however. For the time being, restrict the relevant transformations to produce
only SETCC nodes with a value type matching TLI.getSetCCResultType (or MVT::i1
prior to type legalization).
Fixes PR24636.
llvm-svn: 280767
32 lines
763 B
LLVM
32 lines
763 B
LLVM
; RUN: llc -O0 -fast-isel=0 < %s | FileCheck %s
|
|
target datalayout = "e-m:e-i64:64-n32:64"
|
|
target triple = "powerpc64le-unknown-linux-gnu"
|
|
|
|
@a = external global i32, align 4
|
|
@b = external global i32, align 4
|
|
|
|
; Function Attrs: nounwind
|
|
define void @fn1() #0 {
|
|
entry:
|
|
%0 = load i32, i32* @a, align 4
|
|
%cmp = icmp ne i32 %0, 1
|
|
%conv = zext i1 %cmp to i32
|
|
%1 = load i32, i32* @b, align 4
|
|
%cmp1 = icmp ne i32 0, %1
|
|
%conv2 = zext i1 %cmp1 to i32
|
|
%or = or i32 %conv, %conv2
|
|
%xor = xor i32 1, %or
|
|
%call = call signext i32 @fn2(i32 signext %xor)
|
|
%conv4 = zext i1 undef to i32
|
|
store i32 %conv4, i32* @b, align 4
|
|
ret void
|
|
|
|
; CHECK-LABEL: @fn1
|
|
; CHECK: blr
|
|
}
|
|
|
|
declare signext i32 @fn2(i32 signext)
|
|
|
|
attributes #0 = { nounwind "target-cpu"="ppc64le" }
|
|
|