Re: bug in generating variable names

[Florin Mateoc <fmateoc@yahoo.com>]

Hi Patrick,

Wow, that was a fast reply !
Thank you for the good news.

I would like to ask something related to my
experiment: the jimple output files kept improving
with every iteration. Do you have an idea why (I mean
why didn't the first pass find these jimple-specific
optimization opportunities)?

And an unrelated question: is there a description
somewhere of what was generated automatically with
sablecc and what needed to be done manually on top of
that ? Say if sablecc improves, how easy would it be
to regenerate an "improved" soot ?

Thank you

Florin


--- Patrick LAM <plam@sable.mcgill.ca> wrote:
> Hi Florin,
> 
> On Fri, 8 Jun 2001, Florin Mateoc wrote:
> 
> > void
> > offsetToPointer(soot.coffi.ByteCode) and public
> > soot.coffi.Instruction[]
> > branchpoints(soot.coffi.Instruction)) - in which a
> > variable called $cseTemp0 was declared twice (in
> the
> > first case as two different types).
> 
> This is definitely a bug in my code.  I know how to
> fix it and I'll try to
> get to it tonight.
> 
> The common subexpression elimination phase is a bit
> broken when you read
> in the local variable names for Jimple.  Creating
> bytecode is fine,
> because the local names are not written, but the
> Jimple created is invalid
> in this context.
> 
> [Common subexpression elimination is when you have
> e.g.
> 
>    x = y + z;
>    a = y + z;
> 
> The expression 'y + z' is common to the two
> statements and needs only be
> done once.  So you can write instead,
> 
>    $cseTmp0 = y + z;
>    x = $cseTmp0;
>    a = $cseTmp0;]
> 
> pat
> 
> 


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/