[PATCH] Document HLE metadata

Eric Christopher echristo at gmail.com
Tue Mar 26 22:56:15 PDT 2013


Hi Chris et al,

> > Why?
> >
> > - Fast-isel should be better supported. Some targets may want to exclusively use it.
> >
> > - We are doing more lowering with IR passes using target info including operation and type legality. This works better for loop optimizations.
> >
> > - More optimizations are being done in MI. It's not just CodeGen.
> >
> > - Targets may eventually want to defer some ISEL to manage pass ordering problems, which means it has to be done on MI.
> >
> > - If a feature can be added in IR/MI, why add it add it somewhere that's harder to debug and maintain?
> >
> > I'm probably forgetting important points. There was a BOF on this at the last dev meeting that was recorded.
>
> We don't have the video from the BOF, but the high level concept is that we would like to move away from our SelectionDAG+fastisel duopoly to a point where we have one model that lowers directly from IR to MachineInstrs and then does legalization/combining on MachineInstrs.  In the case that fast isel handles well today (when you have all legal types) this should be just as fast, but would also be fully general (which fast isel isn't), and would allow "whole function" dag combines and other things we've been dreaming of for some time now.
>
> I don't know of anyone planning to do the work, but it sounds like a great future to me. :-)

So, Dan and I have been talking about this for some time (since both
of us worked on fast isel) and we're looking in this direction. We've
got some ideas and are planning on starting both some prototyping of
more selection/legalization as well as expanding some of the existing
lowering. Expect to see some patches and larger work here shortly.
We're definitely open for ideas or collaboration in this area and look
forward to working with the community on this.

-eric




More information about the llvm-commits mailing list