Stepan Dyatkovskiy
2011-Nov-09 07:18 UTC
[LLVMdev] [LLVM, loop-unswitch tests] preserve-analyses.ll, strange PHI instruction.
Hi all. Looking at test/Transforms/LoopUnswitch/preserve-analyses.ll, I found improper phi instruction at string #122: %call.i25.lcssa48 = phi i8* [ %call.i25, %if.then31.i.i ], [ %call.i25, %if.then31.i.i ] ; <i8*> [#uses=0] Is it trick or mistake? -Stepan.
Nick Lewycky
2011-Nov-09 08:12 UTC
[LLVMdev] [LLVM, loop-unswitch tests] preserve-analyses.ll, strange PHI instruction.
Stepan Dyatkovskiy wrote:> Hi all. > > Looking at test/Transforms/LoopUnswitch/preserve-analyses.ll, I found > improper phi instruction at string #122: > %call.i25.lcssa48 = phi i8* [ %call.i25, %if.then31.i.i ], [ %call.i25, > %if.then31.i.i ] ;<i8*> [#uses=0] > Is it trick or mistake?What's improper about it? The block may have two predecessors, both of which are the same block (consider a switch statement with "case 3: case 4: code;"). This is called a critical edge. The requirement in the IR is that a PHI node have an entry for each pred (including duplicates for critical edges) and that the incoming value must be the same. The best test is to ask the verifier (opt -verify). It knows all the special rules, like why this code is legal: define i32 @test() { unreachable %a = add i32 %a, %a ret i32 %a } Surprise! That one's my favourite example. Nick
Duncan Sands
2011-Nov-09 08:24 UTC
[LLVMdev] [LLVM, loop-unswitch tests] preserve-analyses.ll, strange PHI instruction.
Hi Stepan,> Looking at test/Transforms/LoopUnswitch/preserve-analyses.ll, I found > improper phi instruction at string #122: > %call.i25.lcssa48 = phi i8* [ %call.i25, %if.then31.i.i ], [ %call.i25, > %if.then31.i.i ] ;<i8*> [#uses=0] > Is it trick or mistake?if there are several edges from a basic block A to a basic block B (because for example A ends in a conditional branch with both branches leading to B, or A has a switch with several cases leading to B) then A should occur the same number of times in any phi node in B, with the restriction that the value associated with A should be the same each time. In short, the phi node you mention looks fine to me because there are two edges from the switch in %if.then31.i.i to this basic block. Ciao, Duncan.
Stepan Dyatkovskiy
2011-Nov-09 08:38 UTC
[LLVMdev] [LLVM, loop-unswitch tests] preserve-analyses.ll, strange PHI instruction.
OK. Thanks. And if I removed "case 4:" for example. Need I scan all phi nodes and fix it, by removing one predecessor (if it exists) to switch's parent block? -Stepan. Nick Lewycky wrote:> Stepan Dyatkovskiy wrote: >> Hi all. >> >> Looking at test/Transforms/LoopUnswitch/preserve-analyses.ll, I found >> improper phi instruction at string #122: >> %call.i25.lcssa48 = phi i8* [ %call.i25, %if.then31.i.i ], [ %call.i25, >> %if.then31.i.i ] ;<i8*> [#uses=0] >> Is it trick or mistake? > > What's improper about it? > > The block may have two predecessors, both of which are the same block > (consider a switch statement with "case 3: case 4: code;"). This is > called a critical edge. The requirement in the IR is that a PHI node > have an entry for each pred (including duplicates for critical edges) > and that the incoming value must be the same. > > The best test is to ask the verifier (opt -verify). It knows all the > special rules, like why this code is legal: > > define i32 @test() { > unreachable > > %a = add i32 %a, %a > ret i32 %a > } > > Surprise! That one's my favourite example. > > Nick
Possibly Parallel Threads
- [LLVMdev] [LLVM, loop-unswitch tests] preserve-analyses.ll, strange PHI instruction.
- [LLVMdev] [LLVM, loop-unswitch tests] preserve-analyses.ll, strange PHI instruction.
- [LLVMdev] [LLVM] LoopUnswitch + SwitchInst
- How Aggegate Data in R
- [LLVMdev] spilling & xmm register usage