>> Are you sure there isn't any test coverage? As far as I can tell, the tests from https://reviews.llvm.org/rL133503 are still in the tree.I looked at those, but none of them include the full pattern that decomposes into bswap and rol. I debugged through the X86 bswap.ll test and verified none of those cases make it through MatchBSwapHWord (they get handled in MatchBSwapHWordLow instead).>> I don't think there is any existing code to match this particular pattern in instcombine. I guess it wouldn't be hard to add, though.Yes, I guess the InstCombiner::MatchBSwap() function is very similar but not identical. It looks for patterns that match the bswap exactly, whereas the DAGCombiner version is looking for halfword swap patterns that decompose to a bswap and a 16-bit rotate. Jim On 12/8/16, 12:31 PM, "Friedman, Eli" <efriedma at codeaurora.org<mailto:efriedma at codeaurora.org>> wrote: On 12/8/2016 10:01 AM, Jim Lewis via llvm-dev wrote: I’m looking into problems with the function DAGCombiner::MatchBSwapHWord and had a couple questions on how to proceed (I’m new here, and to llvm). It looks like there was never any test coverage for this code, and it doesn’t match the patterns it claims to be looking for. I found a fix for this in our fork, but the fix is even worse in that it matches a whole bunch of invalid patterns as well as the canonical patterns. I have simple test cases that break both the existing code and our local fix. Are you sure there isn't any test coverage? As far as I can tell, the tests from https://reviews.llvm.org/rL133503 are still in the tree. I see equivalent matching code upstream in InstCombiner::MatchBSwap() (InstCombineAndOrXor.cpp), but not an easy way to re-use it AFAICT. Questions: --Is this functionality even worth fixing in DAGCombiner (ie, what is the probability that this complex pattern would re-emerge in codegen after the InstCombiner transform, weighed against the obviously error-prone nature of the matching code)? I don't think there is any existing code to match this particular pattern in instcombine. I guess it wouldn't be hard to add, though. -Eli -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- The information contained in this message is intended only for the recipient, and may be a confidential attorney-client communication or may otherwise be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, any dissemination or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to the message and then deleting it from your computer. Please note that KnuEdge, Inc. reserves the right to monitor and review the content of any electronic message or information sent to or from KnuEdge employee e-mail addresses without informing the sender or recipient of the message. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161208/94355043/attachment.html>
On 12/8/2016 12:05 PM, Jim Lewis wrote:> > >> Are you sure there isn't any test coverage? As far as I can tell, the tests from > https://reviews.llvm.org/rL133503 are still in the tree. > > I looked at those, but none of them include the full pattern that > decomposes into bswap and rol. I debugged through the X86 bswap.ll > test and verified none of those cases make it through MatchBSwapHWord > (they get handled in MatchBSwapHWordLow instead). >The x86 tests don't, but the ARM tests do: see, for example, test6 in test/CodeGen/ARM/rev.ll. If you compile that for x86, you get the expected bswap+rol. -Eli -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161208/67f34b7f/attachment.html>
Thanks, that helps enormously! The issue is that the match is supposed to
support both cascade and tree OR patterns, but there appears to be a problem
with the tree matching. Both test1 and test6 in the ARM tests exercise the
cascade pattern, and I remember now our fix is confined to the tree case.
I hesitate to claim now that there’s no coverage for the tree pattern, but it is
failing to match the patterns we use in our tests, one of which looks like this:
define i32 @test_tree(i32 %x) {
%byte0 = and i32 %x, 255 ; 0x000000ff
%byte1 = and i32 %x, 65280 ; 0x0000ff00
%byte2 = and i32 %x, 16711680 ; 0x00ff0000
%byte3 = and i32 %x, 4278190080 ; 0xff000000
%tmp0 = shl i32 %byte0, 8
%tmp1 = lshr i32 %byte1, 8
%tmp2 = shl i32 %byte2, 8
%tmp3 = lshr i32 %byte3, 8
%or0 = or i32 %tmp0, %tmp1
%or1 = or i32 %tmp2, %tmp3
%result = or i32 %or0, %or1
ret i32 %result
}
I’m still investigating exactly how it’s failing on this one; let me know if I’m
missing something else here.
Jim
On 12/8/16, 2:45 PM, "Friedman, Eli" <efriedma at
codeaurora.org<mailto:efriedma at codeaurora.org>> wrote:
On 12/8/2016 12:05 PM, Jim Lewis wrote:>> Are you sure there isn't any test coverage? As far as I can tell,
the tests from https://reviews.llvm.org/rL133503 are still in the tree.
I looked at those, but none of them include the full pattern that decomposes
into bswap and rol. I debugged through the X86 bswap.ll test and verified none
of those cases make it through MatchBSwapHWord (they get handled in
MatchBSwapHWordLow instead).
The x86 tests don't, but the ARM tests do: see, for example, test6 in
test/CodeGen/ARM/rev.ll. If you compile that for x86, you get the expected
bswap+rol.
-Eli
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
-- The information contained in this message is intended only for the recipient,
and may be a confidential attorney-client communication or may otherwise be
privileged and confidential and protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, any dissemination or copying
of this communication is strictly prohibited. If you have received this
communication in error, please immediately notify us by replying to the message
and then deleting it from your computer. Please note that KnuEdge, Inc. reserves
the right to monitor and review the content of any electronic message or
information sent to or from KnuEdge employee e-mail addresses without informing
the sender or recipient of the message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161209/ca3f7b28/attachment-0001.html>