Kai Plociennik via llvm-dev
2021-Oct-13 08:38 UTC
[llvm-dev] Chains in selection DAG restricting optimization possibilities
Dear all, I have a question about chains in the selection DAG. For our target, we have defined some intrinsics which access memory, and marked the intrinsics to indicate that they do so (e.g. IntrReadMem). The following source code values1[0] = a[0]; values2[0] = a[0]; result[0] = values1[0] + values2[0]; leads to the following part in the selection DAG t0: ch = EntryToken t29: f32,ch = SPECIAL_READ Register:i32 %1, <0>, t0 t13: ch = llvm.spu.store t29:1, <7588>, t29, <0>, ... t28: f32,ch = SPECIAL_READ Register:i32 %1, <0>, t13 t16: ch = llvm.spu.store t28:1, <7588>, t28, <1>, ... so that the chain effectively states that all instructions have to be executed in the given order. However, from looking at the source code, it can be seen that we could e.g. execute the first two statements "... = a[0]" in parallel. My question is: Are we doing something wrong here? Is there a more fine-grained way to define which memory locations could be accessed by our intrinsics so that not-so-restrictive chains would be created? Or should this be done be a special pass in the backend? Any hints would be greatly appreciated. Best regards, Kai Plociennik -- Dr. Kai Plociennik Fraunhofer-Institut für Techno- und Wirtschaftsmathematik ITWM Competence Center High Performance Computing Fraunhofer-Platz 1 67663 Kaiserslautern Tel: +49 (0)631 31600 4081 mail: kai.plociennik at itwm.fraunhofer.de www.itwm.fraunhofer.de
Anton Korobeynikov via llvm-dev
2021-Oct-13 09:36 UTC
[llvm-dev] Chains in selection DAG restricting optimization possibilities
This is exactly the functionality you asked for :) Memory access is all ordered and chains are used to model this order restriction. One could hook alias analysis to "relax chains" and allow scheduler to reorder accesses. On Wed, Oct 13, 2021 at 11:39 AM Kai Plociennik via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > Dear all, > > I have a question about chains in the selection DAG. For our target, we > have defined some intrinsics which access memory, and marked the > intrinsics to indicate that they do so (e.g. IntrReadMem). > > The following source code > > values1[0] = a[0]; > values2[0] = a[0]; > result[0] = values1[0] + values2[0]; > > leads to the following part in the selection DAG > > t0: ch = EntryToken > t29: f32,ch = SPECIAL_READ Register:i32 %1, <0>, t0 > t13: ch = llvm.spu.store t29:1, <7588>, t29, <0>, ... > t28: f32,ch = SPECIAL_READ Register:i32 %1, <0>, t13 > t16: ch = llvm.spu.store t28:1, <7588>, t28, <1>, ... > > so that the chain effectively states that all instructions have to be > executed in the given order. However, from looking at the source code, > it can be seen that we could e.g. execute the first two statements "... > = a[0]" in parallel. > > My question is: Are we doing something wrong here? Is there a more > fine-grained way to define which memory locations could be accessed by > our intrinsics so that not-so-restrictive chains would be created? Or > should this be done be a special pass in the backend? > > Any hints would be greatly appreciated. > > Best regards, > > Kai Plociennik > > -- > Dr. Kai Plociennik > Fraunhofer-Institut für Techno- und Wirtschaftsmathematik ITWM > Competence Center High Performance Computing > Fraunhofer-Platz 1 > 67663 Kaiserslautern > Tel: +49 (0)631 31600 4081 > mail: kai.plociennik at itwm.fraunhofer.de > www.itwm.fraunhofer.de > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- With best regards, Anton Korobeynikov Department of Statistical Modelling, Saint Petersburg State University