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

[Eli Bendersky]

>> 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 was mentioning it in the context of your original patch, proposing
to implement a more general mechanism that seems to make sense (and
here I think Evan says the same), and would also allow you to
implement what you wanted from upstream.

As for making targets slower - there aren't many targets that support
fast isel in the first place (ARM, x86, anything else?) so this
shouldn't be hard to test. And looking at some fast isel stats, maybe
this will make some targets *faster* rather than slower, because
futile target-independent selection won't even be attempted where it
has no chance to succeed.

Eli