[llvm] r176136 - Have a way for a target to opt-out of target-independent fast isel

[Eric Christopher]

On Thu, Feb 28, 2013 at 10:06 AM, Michael Ilseman <milseman at apple.com>wrote:

>
> On Feb 28, 2013, at 8:50 AM, Evan Cheng <evan.cheng at apple.com> wrote:
>
> >
> >
> > On Feb 28, 2013, at 8:38 AM, Eli Bendersky <eliben at google.com> wrote:
> >
> >> On Tue, Feb 26, 2013 at 8:37 PM, Michael Ilseman <milseman at apple.com>
> wrote:
> >>>
> >>> On Feb 26, 2013, at 3:30 PM, Eli Bendersky <eliben at google.com> wrote:
> >>>
> >>>> Can you provide more background for this change? Is it being done for
> >>>> the sake of debugging? What are the intended use cases?
> >>>
> >>> Sure! Debugging can definitely be improved by this, but this also
> gives targets more flexibility. Targets can fast-isel better code with more
> coverage in some situations. For example, SelectOperator(), even when it
> returns false, has side-effects and can schedule IR instructions to be
> fast-iselled that otherwise never would. This becomes particularly
> unfortunate when such instructions trigger the DAG slow-path.
> >>
> >> Thanks for the explanation Michael. Even though you reverted the
> >> change, I want to ask something more general. Your change adds a
> >> methods that's very generally called but only used in one specific
> >> place. If we simply want to prioritize target-specific fast isel over
> >> target-independent fast isel (which sounds like a good idea),
> >> shouldn't more general hooks be added?
> >>
> >
> > One possibly clean solution is just always attempt target-specific fast
> isel first. However, it's possible that would slow down the targets which
> mainly rely on generic fast-isel.
> >
>
> I think you're both saying the same thing :) I was hesitant to change the
> behavior of other targets this way, as there could easily be baked-in
> assumptions about instructions failing independent selection. If there's
> interest, I can investigate further.
>
>
I'm definitely interested. Had no real objections to the idea of the patch,
just wanted to see something to go with it :)

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130228/31ee9d0d/attachment.html>