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>
On 12/9/2016 11:03 AM, Jim Lewis via llvm-dev wrote:> > 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. > >Oh, I see... yes, the existing tree matching logic is complete nonsense. It somehow manages to completely ignore N1, which is where half the value is supposed to come from. -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/20161209/49ac6d21/attachment.html>
Reported via https://llvm.org/bugs/show_bug.cgi?id=31357
On 12/9/16, 1:42 PM, "Friedman, Eli" <efriedma at
codeaurora.org<mailto:efriedma at codeaurora.org>> wrote:
On 12/9/2016 11:03 AM, Jim Lewis via llvm-dev wrote:
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.
Oh, I see... yes, the existing tree matching logic is complete nonsense. It
somehow manages to completely ignore N1, which is where half the value is
supposed to come from.
-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/20161214/58d71067/attachment.html>