search for: afterif

...ut in there (!(idx > 0)) == (idx <= 0) == (idx < 1). Most likely the DAGCombiner is doing this. What should be happening is something like the following: Branch lowering transforms the code into something like the following to save a jump: if (!(idy > 63 && idx > 0)) goto afterif; <code in if> afterif: <code after if> Then, !(idy > 63 && idx > 0) gets combined to (idy < 64 || idx < 1). Then, your legalization transforms the branch condition into (!(idy < 64 || idx < 1) == 0). Then, combine reorganizes this back into (idy > 63 &amp...

Sorry, accidently hit send hotkeys before finishing email. I am still trying to figure out why my comparison instructions are being modified and overall producing incorrect results. The IR produces correct results, but my backend does not and the only thing I can think of is that the IR is treating the Booleans as i1 and therefore either and'ing or xor'ing the results of my

...== (idx <= 0) == (idx < 1). Most likely the DAGCombiner > is doing this. > > What should be happening is something like the following: > Branch lowering transforms the code into something like the following > to save a jump: > if (!(idy > 63 && idx > 0)) goto afterif; > <code in if> > afterif: > <code after if> > > Then, !(idy > 63 && idx > 0) gets combined to (idy < 64 || idx < 1). > > Then, your legalization transforms the branch condition into (!(idy < > 64 || idx < 1) == 0). > > Then, combi...

...f you replaced b with a inside the if statement’s body, then you would introduce UB. The problem arises because after changing %b to %a in LLVM, the load from virtual pointer can be devirtualized to different type. %vtable_a = load %a, !invariant.group;;;; %a == %b%bool = icmp %a, %bbr %bool, %if, %afterif:; if this will be changed to %a, then the optimizer will be able to replace ; %vtable_b with %vtable_a%vtable_b = load %b, !invariant.groupFor other corner cases check out appendix.SolutionThe proposed solution is to model pointers to dynamic types as “fat pointers”. We can think of them as pointer...

...h a inside > the if statement’s body, then you would introduce UB. The problem arises > because after changing %b to %a in LLVM, the load from virtual pointer can > be devirtualized to different type. %vtable_a = load %a, > !invariant.group;;;; %a == %b%bool = icmp %a, %bbr %bool, %if, %afterif:; > if this will be changed to %a, then the optimizer will be able to replace ; > %vtable_b with %vtable_a%vtable_b = load %b, !invariant.groupFor other > corner cases check out appendix.SolutionThe proposed solution is to model > pointers to dynamic types as “fat pointers”. We can thin...

> On Mar 19, 2018, at 7:27 PM, Piotr Padlewski via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > Hi folks, > > here is a link to the proposal that we've been working on lately: > https://docs.google.com/document/d/16GVtCpzK8sIHNc2qZz6RN8amICNBtvjWUod2SujZVEo/edit?usp=sharing