[llvm-dev] Disabling DAGCombine's specific optimization

Ryan Taylor via llvm-dev llvm-dev at lists.llvm.org
Mon May 15 13:36:15 PDT 2017


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>


More information about the llvm-dev mailing list