llvm dev - May 2017 - Disabling DAGCombine's specific optimization

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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170515/cce6d2d6/attachment.html>

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/8f37cbeb/attachment.html>

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/3e06293d/attachment.html>