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

[Michael Ilseman]

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.

> Evan 
> 
>> Eli
>> 
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits