Chains in selection DAG restricting optimization possibilities

Project Infrastructure LLVM Dev List Archives
1

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

2

This is exactly the functionality you asked for :slight_smile: 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.