[llvm-dev] Disabling DAGCombine's specific optimization

[Ryan Taylor via llvm-dev]

I agree. The comment about core code was just a generalization. It was just
an alternative to a DAG solution for Vivek.

On Mon, May 15, 2017 at 5:04 PM, Jon Chesterfield <
jonathanchesterfield at gmail.com> wrote:

> That's interesting. What's the MI equivalent of the work list algorithm
> implemented by dag combine?
>
> In particular, I like that localised improvements to the dag are composed
> automatically and reasonably efficiently. I don't know how to achieve
> composition of back end passes beyond repeatedly applying the same sequence.
>
> Your comment about core code is lost on me though, extra isd nodes and the
> performDAGCombine hook have been sufficient so far.
>
> On 15 May 2017 21:36, "Ryan Taylor" <ryta1203 at gmail.com> wrote:
>
> Why not just create a backend pass to clean this up? Pattern shouldn't be
> too complicated to recognize in MI via use-def. Compartmentalized and you
> don't have to touch core code.
>
> On Mon, May 15, 2017 at 4:29 PM, Jon Chesterfield via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi Vivek,
>>
>> You could work around this by creating a custom ISD node, e.g.
>> MyTargetISD::MyLSHR, with the same type as the general ISD::LSHR. This
>> custom node will then be ignored by the generic DAGCombiner. Convert
>> ISD::LSHR to MyTargetISD::MyLSHR in DAGCombine, optimise it as you see fit,
>> convert it back or lower it directly.
>>
>> I've done this for ISD::CONCAT_VECTORS to avoid an inconvenient
>> conversion to ISD::BUILD_VECTOR. This looks a bit hacky though. I'll watch
>> with interest for a more idiomatic solution.
>>
>> Cheers
>>
>>
>>> >
>>> > On May 15, 2017, at 07:54, vivek pandya via llvm-dev <
>>> > llvm-dev at lists.llvm.org> wrote:
>>> >
>>> > Hello LLVM Developers,
>>> >
>>> > I am working on an architecture which have one bit shift operation if
>>> > barrel shiftier hardware is not present in such cases some DAGCombine
>>> > optimizations reduces performance of certain benchmarks upto 5% for
>>> example
>>> > consider follwing optimization:
>>> > fold (select_cc seteq (and x, y), 0, 0, A) -> (and (shr (shl x)) A)
>>> > Here it introduce 2 shift operations and when barrel shiftier is not
>>> > present these shifts will be converted to loops thus making it worst.
>>> I am
>>> > sure there few architectures which have similar features. So how to
>>> disable
>>> > these kind of optimizations in DAGCombine particularly when I want
>>> build
>>> > and use LLVM for more than one target ?
>>> >
>>> > Sincerely,
>>> > Vivek
>>> > _______________________________________________
>>> > LLVM Developers mailing list
>>> > llvm-dev at lists.llvm.org
>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>> >
>>> >
>>> > Sounds to me like this combine is missing a
>>> TLI.isOperationLegal(ISD::LSHR)
>>> > or similar check
>>> >
>>> I think for me, problem will still be there because shift operation is
>>> legal on my target but it is able to shift only 1 bit at a time and
>>> that's
>>> why I need to convert to loop.
>>> -Vivek
>>>
>>> >
>>> > -Matt
>>> >
>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170515/f6ae8a5c/attachment.html>