Nicolas Geoffray wrote:> Andrew Haley wrote: >> Right, so that part should be trivial. So, does the array bounds check >> elimination already work? If it does, that will considerably reduce >> the work that Andre needs to do. To say the least... >> >> > > Trivial bounds check elimination already work, such as tab[2] = 1; > tab[1] = 2 (the second affectation won't have a bounds checks). Although > I don't know the details, I believe Andre also targets less trivial > eliminations.I should have asked a better question. By "does it work" I meant something like for (int i = 0; i < a.length; i++) System.out.println(a[i]); in which the autogenerated check should trivially be removed, but only if LLVM knows that a.length is invariant. Andrew.
Andrew Haley wrote:> Nicolas Geoffray wrote: >> Andrew Haley wrote: >>> Right, so that part should be trivial. So, does the array bounds check >>> elimination already work? If it does, that will considerably reduce >>> the work that Andre needs to do. To say the least... >>> >>> >> Trivial bounds check elimination already work, such as tab[2] = 1; >> tab[1] = 2 (the second affectation won't have a bounds checks). Although >> I don't know the details, I believe Andre also targets less trivial >> eliminations. > > I should have asked a better question. By "does it work" I meant something > like > > for (int i = 0; i < a.length; i++) > System.out.println(a[i]); > > in which the autogenerated check should trivially be removed, but only if > LLVM knows that a.length is invariant.Oh, I forgot to mention that a.length should be hoisted into a register as it's loop invariant. Andrew.
Andrew Haley wrote:> > I should have asked a better question. By "does it work" I meant something > like > > for (int i = 0; i < a.length; i++) > System.out.println(a[i]); >OK, so no :) VMKit does not know that a[i] is related to a.length. I believe Andre's optimizations will take care of that. Nicolas
Nicolas Geoffray wrote:> Andrew Haley wrote: > >> I should have asked a better question. By "does it work" I meant something >> like >> >> for (int i = 0; i < a.length; i++) >> System.out.println(a[i]); >> >> > > OK, so no :) VMKit does not know that a[i] is related to a.length. I > believe Andre's optimizations will take care of that. > > Nicolas > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >Thanks for all answers. I will consider them all before I start coding. I have another discussion that I would like to hear from you. I can implement SSI in two different ways. Analysis or Transformation Pass. As an Analysis Pass, I would create a SSI LiveInterval, mapping each interval with a constraint. Pros: No change to the IR. Cons: It is a simulation. As an Transformation Pass, SSI would be implemented in the IR with copy instructions (pi functions) and phi functions on the end. Pros: Real SSI. Each interval has a constraint. Cons: IR is bigger, what can impact other optimizations. What do you think? -- Andre Tavares Master Student in Computer Science - UFMG - Brasil http://dcc.ufmg.br/~andrelct