Jon Chesterfield via llvm-dev
2017-May-15 20:29 UTC
[llvm-dev] 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>
Ryan Taylor via llvm-dev
2017-May-15 20:36 UTC
[llvm-dev] Disabling DAGCombine's specific optimization
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>
Jon Chesterfield via llvm-dev
2017-May-15 21:04 UTC
[llvm-dev] Disabling DAGCombine's specific optimization
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>