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...
please, elaborate more on how you see the HARMONY-5500. Especially this:
All HLO optimizations creates necessary instructions "manually". And
sometimes it is not very convenient.
what are examples of not very convenient? I suspect on-the-fly
optimization is not very convenient, but I might be wrong.
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.
