[abc] Re: Glitch in one of the intraprocedural optimizations in Soot?

I looked into this again today and strangely I was unable to reproduce
this behavior. It must have been caused by an unclean build or
something similar. Sorry about the false warning. So everything seems
in order.

Eric

On 26/07/07, Eric Bodden <eric.bodden_at_mail.mcgill.ca> wrote:
> Hi.
>
> I ran the flow-insensitive analysis again for ECOOP and saw that in
> some cases, e.g. antlr/Reader it generates invalid code: The programs
> throw NPEs. Now this is pretty odd, given that the flow-insensitive
> analysis only disables shadows, something that usually cannot trigger
> a NPE.
>
> It turns out that the culprit must be one of the intraprocedural
> optimizations that I used to apply right after weaving (see
> OptFlowInsensitiveAnalysis), in this order:
>
> CopyPropagator
> ConstantPropagatorAndFolder
> OptimizedNullCheckEliminator
> InstanceOfEliminator
> ConditionalBranchFolder
> InstanceOfEliminator
> UnreachableCodeEliminator
> UnusedLocalEliminator
>
> I have yet to figure out, which one it is but I suspect that it is one
> of the newer ones like the null-check eliminator or the instanceof
> eliminator.
>
> I do not really need to run those optimizations if the flow-sensitive
> stage is not active, so I just disabled them for now (applying the
> optimizations that are enabled by default, only).
>
> Nevertheless, I think it's something we should fix before a Soot release.
>
> Assuming that this won't happen before next Friday, can we agree on
> "1.2.2" being the version number for the next abc release? Just so
> that I can tell people something in my talk...
>
> Thanks a lot and apologies for not being able to be too helpful with
> the OOPSLA benchmarks. If I just had more time...
>
> Eric
>
> --
> Eric Bodden
> Sable Research Group
> McGill University, Montréal, Canada
>

-- 
Eric Bodden
Sable Research Group
McGill University, Montréal, Canada