search for: condbr

Hi, Is it intentional that LazyValueInfo.getPredicateAt doesn't solve for the value and only takes assumptions into account? getPredicateAt gets lattice value from cache using getValueAt call: LVILatticeVal LazyValueInfoCache::getValueAt(Value *V, Instruction *CxtI) { ... LVILatticeVal Result; mergeAssumeBlockValueConstantRange(V, Result, CxtI); ... return Result; } Other

...t;pruning as many unreachable CFG > edges as possible " step be more effective -- after finding out which > blocks are reachable from a catch/cleanup, you could intersect that with > the set of blocks from which a corresponding resume can be reached. Any > funclet blocks ending in condbr/switch that only wind up with one successor > in the funclet could then have their terminators rewritten as unconditional > branches, without needing to recover dataflow and chase constants through > phis and resolve compares/switches and all that. > For discussion purposes, let's...

...d be taken if the cleanupblock were entered by an > EH edge, and the normal edge to %normalsucc would be taken otherwise. > > - converting this to landingpads would manifest an i1 that would need > to be set before branching to the cleanupblock, and turn the unwind/resume > into a condbr on that > > - codegen for windows could turn the branch to cleanupblock into a call > to the handler followed by a jump to the %normalsucc > > A change that I'd consider preferable since it avoids the need for an > auxiliary switch in the non-EH code would be: > >...

...d be taken if the cleanupblock were entered by an > EH edge, and the normal edge to %normalsucc would be taken otherwise. > > - converting this to landingpads would manifest an i1 that would need > to be set before branching to the cleanupblock, and turn the unwind/resume > into a condbr on that > > - codegen for windows could turn the branch to cleanupblock into a call > to the handler followed by a jump to the %normalsucc > > A change that I'd consider preferable since it avoids the need for an > auxiliary switch in the non-EH code would be: > >...

On Mon, May 18, 2015 at 12:03 PM, Joseph Tremoulet <jotrem at microsoft.com> wrote: > Hi, > > > > Thanks for sending this out. We're looking forward to seeing this come > about, since we need funclet separation for LLILC as well (and I have > cycles to spend on it, if that would be helpful). > > > > Some questions about the new proposal: > > >