Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 33795 Build 33794: arc lint + arc unit
Event Timeline
llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp | ||
---|---|---|
5774 | Seems like we don't want to nop stuff if volatile. Can you add a FIXME? | |
5804 | Names like this are usually written as /*IsMemset=*/false. clang-tidy recognizes and checks that style. Can you update to follow this style here and otherwhere in the patch? | |
5960 | Ditto on nop'ing volatile. | |
5983 | Seems you want !isVol for AllowOverlap here as well. | |
6068 | Ditto. |
What happens if findOptimalMemOpLowering fails? We have other ways of lowering memcpy/memset that could also violate the "one store per byte" rule.
Yes indeed, I need to take care of this as well.
llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp | ||
---|---|---|
5774 | I'm not familiar with the semantic of Undef here. The documentation says that the SDNode type is undefined but I fail to understand what it means for a volatile copy. Can you explain it to me? | |
5983 | So findOptimalMemOpLowering does not work for memmove when AllowOverlap==true, it generates the correct code for volatile==true (aka AllowOverlap==false) but not for volatile==false: .globl move_7_bytes .p2align 4, 0x90 .type move_7_bytes,@function move_7_bytes: .cfi_startproc # %bb.0: movq (%rsi), %rax movq %rax, (%rdi) retq .Lfunc_end2: .size move_7_bytes, .Lfunc_end2-move_7_bytes .cfi_endproc It definitely looks like a bug but I'm reluctant to touch this code - too complex and not unit tested. Let me know what you think. |
So I've looked at the code, I believe the general case is covered.
What's left is the call to libc's memcpy (which is OK until the standard is updated) and the target specific code: nothing pops out particularly here but I'm not really qualified to review all of it.
BTW I'm not sure Intel's rep movs gives any guarantee on the overlapping access, it's microcoded nowadays.
llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp | ||
---|---|---|
5774 | I think this can be fixed in a later patch: I see volatile as something the compiler isn't allowed to remove from code. Doesn't matter if we're copying something invalid: the programmer asked for something silly, the Standard tells us to honor the silly, so we should. | |
5983 | Leave a FIXME explaining this bug. |
Maybe mention in the commit message that this is explicitly not addressing target-specific code, or calls to memcpy?
I don't agree with the "undef" FIXME (a load/store from undef is UB, whether or not it's volatile), but the check for undef is very unlikely to matter in practice anyway.
Otherwise LGTM.
Seems like we don't want to nop stuff if volatile. Can you add a FIXME?