Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of okko73313@gmail.com
 designates 64.233.184.239 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=BLd4/Juo70e30nZ1Mil4jhdJ8bQ5t5BfNKpW3dh7IdC6gEJmi0u9Q9GUef2pasbA2IzNpmPht2AMP2Rju4zsczdhr6ULpbV6G6KOymHGyUtwuFkjvhFNllPfihjLEghb1/ingO/NKiQtnLAddvxAokufDFahv/DSTJyNpaAaxaE=
Message-ID: <884d1faa0804080236p1b20c30bw7f1b2400a380b224@mail.gmail.com>
Date: Tue, 8 Apr 2008 16:36:53 +0700
From: "Okonechnikov Konstantin" <okko73313@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [general] GSoC 2008 Refactor Java Bytecode Translator
In-Reply-To: <ftesdm$pkv$1@ger.gmane.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_799_4306155.1207647413116"
References: <884d1faa0803192322o7b9f58dfja181970fbe2f882e@mail.gmail.com>
	 <884d1faa0804020307m5abcdaa4waac3916bf6e8bff1@mail.gmail.com>
	 <0vqtzikc6u8.fsf@gmail.com>
	 <884d1faa0804041100j1cdf65c4j771a0203ce4aa4c5@mail.gmail.com>
	 <0vqod8onvd6.fsf@gmail.com> <47F7AC8C.6030200@gmail.com>
	 <884d1faa0804051127tadcf88r9e7ecdf3d83d0271@mail.gmail.com>
	 <ftc4i7$1nm$1@ger.gmane.org> <0vqmyo6mayl.fsf@gmail.com>
	 <ftesdm$pkv$1@ger.gmane.org>

------=_Part_799_4306155.1207647413116
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 4/8/08, George Timoshenko <george.timoshenko@gmail.com> wrote:
>
> Egor Pasko wrote:
>
> But what is the reason not to?
> >
>
> The main value of simplifying-on-the-fly in my opinion is reducing the
> number of generated instructions. Of course, they will be eliminated later
> by separate "simplify", but then you get gaps in instruction ids.
>
> Basing on quite long debugging experience I can say it is a problem when
> you see a lot of instruction sets with non-continuous ids. Such region looks
> suspicious: the instructions were created by different passes, and you have
> to ensure their order and effects are correct. "simplifying-on-the-fly"
> allows to reduce the number of such regions.
>
> The situation reminds me the joke when physicist and mathematician boil
> water on the camp-fire. Removing simplifier and CSE from IRBuilder is a
> mathematician's approach for me.
>
> From another side I understand that from the design point of view The idea
> of IRBuilder cleanup makes translation phase more clear for new participants
> of Jitrino development.
> I can not agree this makes translator easier to debug: just switch OFF the
> flags and you get pure IRBuilder...


Good arguments. I should take them into account.
And as a physicist maybe I have to :)
So, the problem is not exatly with the IrBuilder itself. Well, at least,
It is OK to use it in new translator implementation.


> The main example of IRBuilder availability is HLOAPIMagic pass.
> It is needed there to manage InstructionFactory, a number of nodes for
> generating instructions and labels for them...
> The part of IRBuilder is just copy/pasted there - that is what I want to
> get rid of.
> I agree this is difficult to imagine an HLO pass which needs
> simplification on the fly. But I insist it is needed at the translation.


Pehaps working on replacing HLOAPIMagicIRBuilder in HLOAPIMagic with
IrBuilder or its derived class will
help me to get even better understanding on how IrBuilder works (IMO I got
familiar with it while I was "cleaning it up"). But of course, I will
require community help & support. Also it's not clear for me yet how
much time will it take me to manage this task, if I am assigned to it.
And I am not quite sure if this task is in the scope of the translator
project.

------=_Part_799_4306155.1207647413116--