Displaying 20 results from an estimated 1000 matches similar to: "ConstantFoldTerminator doesn't delete trivially dead phi inputs"
2017 May 01
4
RFC: Stop using redundant PHI node entries for multi-edge predecessors
Hi,
On Mon, May 1, 2017 at 8:47 AM, Daniel Berlin via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>> Today, the IR requires that if you have multiple edges from A to B
>> (typically with a switch) any phi nodes in B must have an equal number of
>> entries for A, but that all of them must have the same value.
>
>> This seems rather annoying....
>> 1) It
2011 Feb 01
0
[LLVMdev] Loop simplification
Here's what I've got so far - it seems to work, aside from the fact that
DeleteDeadPHIs is not removing at least one dead PHI in my test program.
---------------------
static bool
mergeBlockIntoSuccessor(BasicBlock *pred, BasicBlock *succ)
{
if (succ == pred)
return false;
if (pred->getFirstNonPHI() != pred->getTerminator())
return false;
//
2011 Feb 01
3
[LLVMdev] Loop simplification
On Feb 1, 2011, at 1:34 PM, Andrew Trick wrote:
> On Feb 1, 2011, at 1:08 PM, Andrew Clinton wrote:
>
>> I have a (non-entry) basic block that contains only PHI nodes and an
>> unconditional branch (that does not branch to itself). Is it always
>> possible to merge this block with it's successor and produce a
>> semantically equivalent program? I'm
2012 Mar 08
2
[LLVMdev] Updating value from PHI
Here is the code snippet that I am using to create the PHIs in the loop
according to the PHIs in the new preheader. At this point I have already
redirected the loop backedge and removed the preheader from the loop.
for (BasicBlock::iterator II = loopHeaderBB->begin();
(PN=dyn_cast<PHINode>(II)); ++II) {
// remove loop back PHI and add it to split BB
2017 May 01
3
RFC: Stop using redundant PHI node entries for multi-edge predecessors
Today, the IR requires that if you have multiple edges from A to B
(typically with a switch) any phi nodes in B must have an equal number of
entries for A, but that all of them must have the same value.
This seems rather annoying....
1) It creates multiple uses of values in A for no apparently good reason
2) It makes updating PHI nodes using sets of predecessors incredibly hard
3) There is no
2012 Mar 08
0
[LLVMdev] Updating value from PHI
I guess I thought that once I redirected the branches and created new PHIs
that LLVM would correct the variable usage when I return true (changed CFG)
from the pass. Is this not the case?
On Wed, Mar 7, 2012 at 4:08 PM, Ryan Taylor <ryta1203 at gmail.com> wrote:
> Here is the code snippet that I am using to create the PHIs in the loop
> according to the PHIs in the new preheader. At
2015 Aug 10
3
Possible bug in adjusting PHINode from removePredecessor?
Hi,
Simple description of the problem below. I have code coming into
pruneEH as follows
fn a {
entry:
call fn b
...
for_cond:
%i = phi [1, entry] [%x, for_body]
cmp $i with someval
cond-br for_body or for_exit
for_body:
...
$x = $i + 1
branch for_cond
for_exit
...
}
PruneEH determines that the call to fn-b won't return. The code is
modified thus.
fn a {
entry:
call fn b
unreachable insn
2008 Sep 27
2
[LLVMdev] SwitchInstr::removeCase() doesn't remove PHINodes' predecessors
Hi,
I've been writing an optimization pass (described on the ML previously).
Sometimes this pass removes some case entries from switch instructions,
which cause an abort because removeCase() doesn't fix the PHINodes
predecessors when needed.
e.g.:
define i32 @foo() nounwind {
ifthen:
%call = call i32 @bar()
switch i32 %call, label %myphi [
i32 0, label %ifelse
i32 1, label
2008 Sep 27
0
[LLVMdev] SwitchInstr::removeCase() doesn't remove PHINodes' predecessors
Nuno Lopes wrote:
> PHINode should have one entry for each predecessor of its parent basic
> block!
> %ret.0 = phi i32 [ 0, %ifthen ], [ 1, %ifelse ] ; <i32>
> [#uses=1]
> Broken module found, compilation aborted!
>
> This is because myphi is not reachable from ifthen anymore. My question is:
> is this a bug (or missing feature) or do I need to
2018 Jun 29
2
Cleaning up ‘br i1 false’ cases in CodeGenPrepare
> we lower llvm.objectsize later than we should
Is there a well-accepted best (or even just better) place to lower
objectsize? I ask because I sorta fear that these kinds of problems will
become more pronounced as llvm.is.constant, which is also lowered in CGP,
gains popularity.
(To be clear, I think it totally makes sense to lower is.constant and
objectsize in the same place. I'm just
2018 Jun 29
2
Cleaning up ‘br i1 false’ cases in CodeGenPrepare
Hi,
I have come across a couple of cases where the code generated after
CodeGenPrepare pass has "br i1 false .." with both true and false
conditions preserved and this propagates further and remains the same
in the final assembly code/executable.
In CodeGenPrepare::runOnFunction, ConstantFoldTerminator (which
handles the br i1 false condition) is called only once and if after
the
2012 Mar 08
0
[LLVMdev] Updating value from PHI
I have attached a case of what I am trying to do, I'm pretty sure I'm just
missing some simple API call. In the cfg you can see that although Im
setting "lsr.iv441" as "lsr.iv44" from for.body.387.i it's not propagating
that through the block or graph.
On Wed, Mar 7, 2012 at 12:03 PM, Ryan Taylor <ryta1203 at gmail.com> wrote:
> I am splitting a one BB
2012 Mar 07
4
[LLVMdev] Updating value from PHI
I am splitting a one BB loop into two BB.
Basically, the one loop BB has 3 incoming values, one form back edge two
from other edges. I want to extract the PHIs from the other two edges out
into it's own BB and delete that from the loop, then redirect the backedge
to the loopbody (non extracted portion) and create a new PHI coming from
the extracted BB and the backedge.
I can do this;
2009 Dec 03
2
[LLVMdev] Preserving ProfileInfo in several Passes
Hi all,
this (altough a big patch) is actually pretty straight forward: It
(tries) to preserve ProfileInfo in all -std-compile-opts passes and all
X86-Backend passes.
There is still some passes that have corner cases where the ProfileInfo
is not correct after the pass. Some passes are still missing...
How shall I proceed with this?
Andi
-------------- next part --------------
A non-text
2017 Apr 28
2
[MemorySSA] A question about how to update the MemorySSA when we call RecursivelyDeleteTriviallyDeadInstructions
When we erase a memory access instruction, existing passes using
memory ssa like GVN, NewGVN, GVNHoist and EarlyCSE uses
MemorySSAUpdater to do the update before the instruction is erased.
However, if we call llvm::RecursivelyDeleteTriviallyDeadInstructions
to find out dead instruction recursively and memory access
instructions may be erased inside the recursive process, we need a way
to update
2009 Dec 03
0
[LLVMdev] Preserving ProfileInfo in several Passes
Hello,
Here are a few misc. comments on this patch.
Would it make sense to mark the ProfileInfo passes as "CFGOnly?"
If so, that would let them be automatically preserved by passes
which don't modify the CFG (and that call AU.setPreservesCFG()).
> + if (ProfileInfo* PI = getAnalysisIfAvailable<ProfileInfo>()) {
> + PI->splitEdge(OrigPreHeader, NewHeader,
2014 Oct 18
2
[LLVMdev] Dereferencing NULL pointer in IndVarSimplify.cpp?
Hi,
Here is the code in IndVarSimplify.cpp.
SmallVector<WeakVH, 16> DeadInsts;
while (!DeadInsts.empty())
if (Instruction *Inst =
dyn_cast_or_null<Instruction>(&*DeadInsts.pop_back_val()))
RecursivelyDeleteTriviallyDeadInstructions(Inst, TLI);
Since DeadInsts.pop_back_val() is WeakVH which could hold a NULL
pointer, the expression,
2009 May 08
2
[LLVMdev] Splitting a basic block, replacing it's terminator
Hi,
I want to insert a conditional branch in the middle of a basic block.
To that end, I am doing these steps:
(1) Split the basic block:
bb->splitBasicBlock()
(2) Remove the old terminator:
succ->removePredecessor(bb)
bb->getTerminator()->getParent()
(3) Adding a new terminator:
BranchInst::Create(ifTrue, ifFalse, cnd, "", bb);
That seems to work, but later passes
2013 Mar 02
2
[LLVMdev] Question about method CodeExtractor::severSplitPHINodes
Hi folks,
Hope this is not a silly question. But it bothers me when I am thinking
about it.
My question is:
1. In the implementation of serverSplitPHINodes(), why it only checks the
first PHI node for possible
multiple inputs from outside the region to extract. There could be more
than one PHI nodes in the header
block, and the code only checks the first one. I don't quite get it.
2016 Aug 24
2
LLVM 3.9 RC2's SCCP pass removing calls to external functions?!
Hi Félix,
Sanjoy Das wrote:
> Félix Cloutier via llvm-dev wrote:
> > Assuming that this is a bug, what are the next steps?
>
> Looks like you already have a very small test case -- have you tried
> sticking it in a debugger to see why SCCP thinks removing the call is
> okay?
>
> Alternatively, file a bug at llvm.org/bugs and someone will get to it.
The third