Jean Perier via llvm-dev
2021-Nov-22 15:05 UTC
[llvm-dev] When is it OK to use loads and stores with struct types ?
Hi,
I would like to understand better the implications of using loads and stores
with struct types in LLVM IR.
It seems that using loads and stores on struct types leads to troubles as the
struct size grows (detailed observations below).
Hence my questions:
- Is it reasonable/better to use stores and loads with some struct types or
should llvm.memcpy always be preferred ?
- Is there an official limitation on the size of struct types that can be used
in load and store operations ?
Thanks in advance for the guidance,
Jean Perier
Here are more details about what I have observed with struct type loads and
stores. Take the example:
%t = type { [N x i8] }
define void @foo(%t* %0, %t* %1) {
%3 = load %t, %t* %1
store %t %3, %t* %0
ret void
}
I noticed that:
- llc compile times are not linear at all with `N` (with a debug build on a
powerful machine, N=100 -> 0.05s, N=500 -> 1.4s, N = 1000 -> 2.25s, N =
2000 : 12.5s. ... N= 65535 : more than 22 minutes, I did not wait).
- llc hits a first assert when `N` >= 65536 (at [1] in the code, reported 10
years ago in bug [2]).
- llc hits a different assert when `N` >= 2097153 (at [3] in the code,
reported a year ago in bugs [4])
All this leads me to question if I should produce LLVM IR that loads/stores
struct types, or just always use llvm.memcpy for them. Why is it allowed to
load/store them if it can lead to trouble ?
[1]
https://github.com/llvm/llvm-project/blob/4c484f11d355e4293f7b245a9330f0a1e89630ac/llvm/include/llvm/CodeGen/SelectionDAGNodes.h#L1069
[2] https://bugs.llvm.org/show_bug.cgi?id=7250 and more recently duplicated in
https://bugs.llvm.org/show_bug.cgi?id=37000
[3]
https://github.com/llvm/llvm-project/blob/4c484f11d355e4293f7b245a9330f0a1e89630ac/llvm/lib/IR/Type.cpp#L315
[4] https://bugs.llvm.org/show_bug.cgi?id=48615 and
https://bugs.llvm.org/show_bug.cgi?id=50913
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211122/cd789f2c/attachment-0001.html>
Philip Reames via llvm-dev
2021-Nov-22 16:23 UTC
[llvm-dev] When is it OK to use loads and stores with struct types ?
Not specifically on the topic you ask about, but we do have some general advice on IR features to prefer vs avoid here: https://llvm.org/docs/Frontend/PerformanceTips.html Philip On 11/22/21 7:05 AM, Jean Perier via llvm-dev wrote:> > Hi, > > I would like to understand better the implications of using loads and > stores with struct types in LLVM IR. > > It seems that using loads and stores on struct types leads to troubles > as the struct size grows (detailed observations below). > > Hence my questions: > > - Is it reasonable/better to use stores and loads with some struct > types or should llvm.memcpy always be preferred ? > > - Is there an official limitation on the size of struct types that can > be used in load and store operations ? > > Thanks in advance for the guidance, > > Jean Perier > > Here are more details about what I have observed with struct type > loads and stores. Take the example: > > ///%t = type { [N x i8] }/ > > / define void @foo(%t* %0, %t* %1) {/ > > / %3 = load %t, %t* %1/ > > / store %t %3, %t* %0/ > > / ret void/ > > / }/ > > I noticed that: > > - llc compile times are not linear at all with `N` (with a debug build > on a powerful machine, N=100 -> 0.05s, N=500 -> 1.4s, N = 1000 -> > 2.25s, N = 2000 : 12.5s. … N= 65535 : more than 22 minutes, I did not > wait). > > - llc hits a first assert when `N` >= 65536 (at [1] in the code, > reported 10 years ago in bug [2]). > > - llc hits a different assert when `N` >= 2097153 (at [3] in the code, > reported a year ago in bugs [4]) > > All this leads me to question if I should produce LLVM IR that > loads/stores struct types, or just always use llvm.memcpy for them. > Why is it allowed to load/store them if it can lead to trouble ? > > [1] > https://github.com/llvm/llvm-project/blob/4c484f11d355e4293f7b245a9330f0a1e89630ac/llvm/include/llvm/CodeGen/SelectionDAGNodes.h#L1069 > <https://github.com/llvm/llvm-project/blob/4c484f11d355e4293f7b245a9330f0a1e89630ac/llvm/include/llvm/CodeGen/SelectionDAGNodes.h#L1069> > > [2] https://bugs.llvm.org/show_bug.cgi?id=7250 > <https://bugs.llvm.org/show_bug.cgi?id=7250> and more recently > duplicated in https://bugs.llvm.org/show_bug.cgi?id=37000 > <https://bugs.llvm.org/show_bug.cgi?id=37000> > > [3] > https://github.com/llvm/llvm-project/blob/4c484f11d355e4293f7b245a9330f0a1e89630ac/llvm/lib/IR/Type.cpp#L315 > <https://github.com/llvm/llvm-project/blob/4c484f11d355e4293f7b245a9330f0a1e89630ac/llvm/lib/IR/Type.cpp#L315> > > [4] https://bugs.llvm.org/show_bug.cgi?id=48615 > <https://bugs.llvm.org/show_bug.cgi?id=48615> and > https://bugs.llvm.org/show_bug.cgi?id=50913 > <https://bugs.llvm.org/show_bug.cgi?id=50913> > > > _______________________________________________ > 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/20211122/a764cd80/attachment.html>