James Y Knight via llvm-dev
2021-Apr-14 18:57 UTC
[llvm-dev] [RFC] [X86] Emit unaligned vector moves on avx machine with option control.
This is not a principled change -- it avoids a problem arising from *one* use of alignment information, but there are other uses of alignment in LLVM, and those will still cause problems, potentially less clearly. So, I think that this will not be a useful option to provide to users, in this form. What I suspect you *actually* want here is an option to tell Clang not to infer load/store alignments based on object types or alignment attributes -- instead treating everything as being potentially aligned to 1 unless the allocation is seen (e.g. global/local variables). Clang would still need to use the usual alignment computation for variable definitions and structure layout, but not memory operations. If clang emits "load ... align 1" instructions in LLVM IR, the right thing would then happen in the X86 backend automatically. My initial inclination is that this feature is also not particularly worthwhile to implement, but I'm open to being convinced that this is indeed valuable enough to be worthwhile. It should actually work reliably, and is somewhat in line with other such "not-quite-C" flags we provide (e.g. -fno-delete-null-pointer-checks). Of course, even with such an implementation, you can still have a problem with user code depending on alignof() returning a reliable answer (e.g., llvm::PointerUnion). Not much can be done about that. On Wed, Apr 14, 2021 at 2:07 PM Liu, Chen3 via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi all. > > > > We want to make a patch to always emit unaligned vector move instructions > on AVX machine with option control. We do this for the following reason: > > > > 1. With AVX the performance for aligned vector move and unaligned > vector move on X86 are the same if the address is aligned. In this case we > prefer to use unaligned move because it can avoid some run time exceptions; > 2. This fixes an inconsistency in optimization: suppose a load > operation was merged into another instruction (e.g., load and add becomes > `add [memop]'). If a misaligned pointer is passed to the two-instruction > sequence, it will > > raise an exception. If the same pointer is passed to the memop > instruction, it will work. Thus, the behavior of misalignment depends upon > what optimization levels and passes are applied, and small source changes > could cause > > issues to appear and disappear. It's better for the user to consistently > use unaligned load/store to improve the debug experience; > > 1. Makes good use of HW that is capable of handling misaligned data > gracefully. It is not necessarily a bug in users code but a third-part > library. For example it would allow using a library built in old ages where > stack alignment was 4-byte only. > 2. Compatible with ICC so that users can easily use llvm; > > > > Roman Lebedev is worried that this patch will hide UB. In our opinions, UB > doesn't have to mean raise an exception. The example code( > https://godbolt.org/z/43bYPraoa) does have UB behavior but it is still > valid (and reasonable) to interpret that UB as `go slower', > > instead of `raise exception'. Besides, as default we still emit aligned > instructions as before, but we provide an option for users with this need. > > > > We have two patches discussing this issue, one of which has been abandoned: > > https://reviews.llvm.org/D88396 (abandoned) > > https://reviews.llvm.org/D99565 (in review) > > > > Thanks. > > Chen Liu. > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://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/20210414/9ef0e479/attachment.html>
Craig Topper via llvm-dev
2021-Apr-14 19:41 UTC
[llvm-dev] [RFC] [X86] Emit unaligned vector moves on avx machine with option control.
When would you recommend a user should use this flag as proposed? Anytime they moved code from icc? Or after they encounter an exception, should they use this flag to get rid of the exception rather than using tools like ubsan to find the bug in their code? Where would we document recommendations so that users know the tradeoffs and risks? Your patch is only doing this for AVX and not SSE because folding loads requires alignment with SSE, but not AVX. So users that need to support non-AVX CPUs have to fix their bugs and can't sweep them away with this flag. I'm somewhat ok with unconditionally using unaligned instructions on AVX because then there is no command line option to explain to users. But then there's probably a group of people out there that want the alignment check. ~Craig On Wed, Apr 14, 2021 at 11:58 AM James Y Knight via llvm-dev < llvm-dev at lists.llvm.org> wrote:> This is not a principled change -- it avoids a problem arising from *one* use > of alignment information, but there are other uses of alignment in LLVM, > and those will still cause problems, potentially less clearly. So, I think > that this will not be a useful option to provide to users, in this form. > > What I suspect you *actually* want here is an option to tell Clang not to > infer load/store alignments based on object types or alignment attributes > -- instead treating everything as being potentially aligned to 1 unless the > allocation is seen (e.g. global/local variables). Clang would still need to > use the usual alignment computation for variable definitions and structure > layout, but not memory operations. If clang emits "load ... align 1" > instructions in LLVM IR, the right thing would then happen in the X86 > backend automatically. > > My initial inclination is that this feature is also not > particularly worthwhile to implement, but I'm open to being convinced that > this is indeed valuable enough to be worthwhile. It should actually work > reliably, and is somewhat in line with other such "not-quite-C" flags we > provide (e.g. -fno-delete-null-pointer-checks). Of course, even with such > an implementation, you can still have a problem with user code depending on > alignof() returning a reliable answer (e.g., llvm::PointerUnion). Not much > can be done about that. > > > On Wed, Apr 14, 2021 at 2:07 PM Liu, Chen3 via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi all. >> >> >> >> We want to make a patch to always emit unaligned vector move instructions >> on AVX machine with option control. We do this for the following reason: >> >> >> >> 1. With AVX the performance for aligned vector move and unaligned >> vector move on X86 are the same if the address is aligned. In this case we >> prefer to use unaligned move because it can avoid some run time exceptions; >> 2. This fixes an inconsistency in optimization: suppose a load >> operation was merged into another instruction (e.g., load and add becomes >> `add [memop]'). If a misaligned pointer is passed to the two-instruction >> sequence, it will >> >> raise an exception. If the same pointer is passed to the memop >> instruction, it will work. Thus, the behavior of misalignment depends upon >> what optimization levels and passes are applied, and small source changes >> could cause >> >> issues to appear and disappear. It's better for the user to consistently >> use unaligned load/store to improve the debug experience; >> >> 1. Makes good use of HW that is capable of handling misaligned data >> gracefully. It is not necessarily a bug in users code but a third-part >> library. For example it would allow using a library built in old ages where >> stack alignment was 4-byte only. >> 2. Compatible with ICC so that users can easily use llvm; >> >> >> >> Roman Lebedev is worried that this patch will hide UB. In our opinions, >> UB doesn't have to mean raise an exception. The example code( >> https://godbolt.org/z/43bYPraoa) does have UB behavior but it is still >> valid (and reasonable) to interpret that UB as `go slower', >> >> instead of `raise exception'. Besides, as default we still emit aligned >> instructions as before, but we provide an option for users with this need. >> >> >> >> We have two patches discussing this issue, one of which has been >> abandoned: >> >> https://reviews.llvm.org/D88396 (abandoned) >> >> https://reviews.llvm.org/D99565 (in review) >> >> >> >> Thanks. >> >> Chen Liu. >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://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/20210414/66966702/attachment.html>
Philip Reames via llvm-dev
2021-Apr-14 22:43 UTC
[llvm-dev] [RFC] [X86] Emit unaligned vector moves on avx machine with option control.
+1 to what James said. My reaction to the original proposal is a strong -1, and James did a good job of explaining why. Philip On 4/14/21 11:57 AM, James Y Knight via llvm-dev wrote:> This is not a principled change -- it avoids a problem arising from > /one/ use of alignment information, but there are other uses of > alignment in LLVM, and those will still cause problems, potentially > less clearly. So, I think that this will not be a useful option to > provide to users, in this form. > > What I suspect you /actually/ want here is an option to tell Clang not > to infer load/store alignments based on object types or alignment > attributes -- instead treating everything as being potentially aligned > to 1 unless the allocation is seen (e.g. global/local variables). > Clang would still need to use the usual alignment computation for > variable definitions and structure layout, but not memory operations. > If clang emits "load ... align 1" instructions in LLVM IR, the right > thing would then happen in the X86 backend automatically. > > My initial inclination is that this feature is also not > particularly worthwhile to implement, but I'm open to being convinced > that this is indeed valuable enough to be worthwhile. It should > actually work reliably, and is somewhat in line with other such > "not-quite-C" flags we provide (e.g. -fno-delete-null-pointer-checks). > Of course, even with such an implementation, you can still have a > problem with user code depending on alignof() returning a reliable > answer (e.g., llvm::PointerUnion). Not much can be done about that. > > > On Wed, Apr 14, 2021 at 2:07 PM Liu, Chen3 via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Hi all. > > We want to make a patch to always emit unaligned vector move > instructions on AVX machine with option control. We do this for > the following reason: > > 1. With AVX the performance for aligned vector move and unaligned > vector move on X86 are the same if the address is aligned. In > this case we prefer to use unaligned move because it can avoid > some run time exceptions; > 2. This fixes an inconsistency in optimization: suppose a load > operation was merged into another instruction (e.g., load and > add becomes `add [memop]'). If a misaligned pointer is passed > to the two-instruction sequence, it will > > raise an exception. If the same pointer is passed to the memop > instruction, it will work. Thus, the behavior of misalignment > depends upon what optimization levels and passes are applied, and > small source changes could cause > > issues to appear and disappear. It's better for the user to > consistently use unaligned load/store to improve the debug experience; > > 3. Makes good use of HW that is capable of handling misaligned > data gracefully. It is not necessarily a bug in users code but > a third-part library. For example it would allow using a > library built in old ages where stack alignment was 4-byte only. > 4. Compatible with ICC so that users can easily use llvm; > > Roman Lebedev is worried that this patch will hide UB. In our > opinions, UB doesn't have to mean raise an exception. The example > code(https://godbolt.org/z/43bYPraoa > <https://godbolt.org/z/43bYPraoa>) does have UB behavior but it is > still valid (and reasonable) to interpret that UB as `go slower', > > instead of `raise exception'. Besides, as default we still emit > aligned instructions as before, but we provide an option for > users with this need. > > We have two patches discussing this issue, one of which has been > abandoned: > > https://reviews.llvm.org/D88396 <https://reviews.llvm.org/D88396> > (abandoned) > > https://reviews.llvm.org/D99565 <https://reviews.llvm.org/D99565> > (in review) > > Thanks. > > Chen Liu. > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://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/20210414/50853178/attachment-0001.html>
Reid Kleckner via llvm-dev
2021-Apr-15 16:58 UTC
[llvm-dev] [RFC] [X86] Emit unaligned vector moves on avx machine with option control.
On Wed, Apr 14, 2021 at 11:58 AM James Y Knight via llvm-dev < llvm-dev at lists.llvm.org> wrote:> What I suspect you *actually* want here is an option to tell Clang not to > infer load/store alignments based on object types or alignment attributes > -- instead treating everything as being potentially aligned to 1 unless the > allocation is seen (e.g. global/local variables). Clang would still need to > use the usual alignment computation for variable definitions and structure > layout, but not memory operations. If clang emits "load ... align 1" > instructions in LLVM IR, the right thing would then happen in the X86 > backend automatically. >This sounds like the -fmax-type-align flag: https://clang.llvm.org/docs/UsersManual.html#controlling-code-generation Explicit alignment attributes are still honored, so some aligned vector instructions may be generated. However, the documentation describes essentially this exact use case. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210415/fc06a424/attachment.html>