summaryrefslogtreecommitdiffstats
path: root/content/zettel/1c2b1.md
diff options
context:
space:
mode:
Diffstat (limited to 'content/zettel/1c2b1.md')
-rw-r--r--content/zettel/1c2b1.md28
1 files changed, 28 insertions, 0 deletions
diff --git a/content/zettel/1c2b1.md b/content/zettel/1c2b1.md
new file mode 100644
index 0000000..cb42985
--- /dev/null
+++ b/content/zettel/1c2b1.md
@@ -0,0 +1,28 @@
++++
+title = "Memory Aliasing"
+author = "Yann Herklotz"
+tags = []
+categories = []
+backlinks = ["1c2b"]
+forwardlinks = ["1c7", "1c2c"]
+zettelid = "1c2b1"
++++
+
+One problem with scheduling, and list scheduling in particular as it is
+a relatively simple scheduling model, is that loads and stores cannot be
+scheduled correctly. This is because dependencies cannot be calculated
+properly between loads and stores, so one cannot know if these were done
+in parallel or not.
+
+One solution is to use polyhedral analysis ([\#1c7]) with loads and
+stores that have some kind of induction variable, as is present in loop
+pipelining ([\#1c2c]).
+
+The problem in C is that there is no aliasing information about
+pointers, and they can therefore point to same memory location. However,
+strict aliasing in GCC, for example, can allow for aliasing information
+about pointers of different types, as GCC assumes that these cannot
+point to the same data structure.
+
+ [\#1c7]: /zettel/1c7
+ [\#1c2c]: /zettel/1c2c