On 9/9/2021 4:15 AM, Richard Biener wrote:
b) Even though we can seemingly fold everything DOM/threader does, in
order to replace it with a backward threader instance we'd have to merge
the cost/profitability code scattered throughout the forward threader,
as well as the EDGE_FSM* / EDGE_COPY* business.
c) DOM changes the IL as it goes. Though we could conceivably divorce
do the threading after DOM is done.
Yeah, it does not actually process/simplify the blocks copied by threading.
In fact I think it only registers jump threading opportunities during the DOM
walk and commits them only later. But it of course uses its avail / copies
stack to find them - that part you cannot easily divorce.
Well, divorcing from using the context sensitive avail/copies is part of
what Aldy & Andrew have been working on. All indications I've seen are
they're on track to be able to do that.
And yes, it only registers the threads and waits until after DOM is done
to transform the CFG. That in and of itself introduces all kinds of
complexity. If we can get to the point where we don't need the context
sensitive avail/copies, then we've got a real shot at untangling DOM and
threading which would be a huge maintainability win in my mind.
DOM is also yet another value-numbering framework - one could think
of stripping it down from that side, keeping the threading bits only
(but you'd still have the avail / copies bits).
Yes. I think you and I touched on this a while back. At a high level
I'd prefer to have FRE rather than DOM doing the bulk of the redundant
expression elimination. The big blocker there was the tight integration
of DOM and threading. But if Aldy can untangle that we can then
evaluate replacing DOM with FRE.
That said, it has one nice property it can leverage due to its incredibly
simple memory redundancy handling, in that it usually performs way less
alias queries than FRE (even when you run the latter in non-iterative mode).
DOM as an infrastructure for optimization is probably reaching the end
of its useful life. FRE has a lot more going for it.
But the same way DOM can register jump threading opportunities FRE
could do as well.
I'd advise against that and instead look towards a model where no pass
has integrated jump threading and the only jump threading module we have
is the backwards threader.
jeff
