On the 0x420 day of Apache Harmony Alexei Fedotov wrote: > > physicist > AFAIK, NSU graduates in physics become incomparable programmers.
I am a mathematician, do not start a holywar here :) > On Tue, Apr 8, 2008 at 1:36 PM, Okonechnikov Konstantin > <[EMAIL PROTECTED]> wrote: > > On 4/8/08, George Timoshenko <[EMAIL PROTECTED]> 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. > > > > > > -- > With best regards, > Alexei > -- Egor Pasko
