One thing that might fix it is to tell LLVM that the class field of
all objects is constant. Maybe vmkit has already done this, though.
I think this involves writing a custom alias analysis pass. LLVM
needs to have enough information to know that between the instanceof
and the cast o's pointer hasn't been modified and that o->class is
the
same.
It may be easier to fix in your frontend if you do a dataflow analysis
where you build up type information about objects based on instanceof
checks and ifs and eliminate the check, though.
Reid
On Thu, Nov 19, 2009 at 11:59 AM, Alysson <aishofpf at gmail.com>
wrote:> Hi all,
>
> I wrote you some days ago about one project that I want to do on vmkit:
> I want to remove redundant instanceof tests. I am right now looking at the
> LLVM code that vmkit produces for java files, but I am finding it very
> difficult to identify the code that is produced by each instanceof. Would
it
> be possible for you guys to give me some pointers on how to attack this
> problem? Should I focus on the vmkit front-end, or should I perform this
> type of optimization directly in LLVM, as a function pass?
>
> Just to give you context, the optimization that I want to perform is to
> remove redundant instanceof's that are inserted by vmkit to ensure that
the
> code does not do unsafe casts at runtime. For instance, if I code the
> program:
>
> if (o instanceof String)
> String s = (String)o;
>
> then vmkit will most likely insert a second test in the code, like this:
>
> if (o instanceof String) {
> if (!o instanceof String)
> throw ClassCastException
> String s = (String)o;
> }
>
> Thanks in advance,
>
> Alysson
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>