freenode/#clasp - IRC Chatlog
Search
5:44:08
karlosz
its actually realtively easy to tell which <- instructions are actually needed in the flowgraph. if a <- instructions's target node has only 1 def, and either the source node has 1 def or the target has 1 use, then the <- instruction can be eliminated, with the source and target nodes merging into one node
5:45:00
karlosz
that's the algorithm i'm using to only produce the minimum amount of runtime store and loads from <- instructions
5:45:34
karlosz
perhaps that can be the basis for a general purpose HIR pass that cleans up the <- nodes
11:29:30
drmeister
karlosz: Do you have a Common Lisp function that can take HIR and carry out this transformation?
12:52:05
drmeister
::notify DVSSA Here is a good link that describes the Rosetta atom tree https://www.rosettacommons.org/docs/latest/getting_started/Getting-Started
13:03:28
Bike
drmeister: build failed. the error is comprehensible except i'm not sure where it's coming from
13:04:59
Bike
i'm wondering if maybe it isn't kosher to alter an instruction after generating other instructions
13:06:09
Bike
what i'm doing in landing-pad.lisp is generating a landing pad, then generating some other instructions, then adding clauses to the landing pad
13:06:10
drmeister
Ok - we have a landing pad that has no clauses and is not indicated as being a cleanup - that should be easy.
13:06:56
Bike
also, re karlosz's transformation, i'm pretty sure i wrote out something like that, but it wasn't adequate for what i wanted it for (simplifying analysis) so i didn't pursue it
13:07:26
drmeister
It's ok, you just need to get the info going to the right place. There are these things called IRBuilder(s) - they are like cursors that point to where the next instruction is going. If you don't keep them updated properly info will go to the wrong place.
13:07:47
Bike
that controls it even for something like add-clause that takes the landing pad as an argument?