[llvm-dev] "Ordered" Instruction Iterator?

David Chisnall via llvm-dev llvm-dev at lists.llvm.org
Tue Jun 1 06:25:34 PDT 2021


Hi,

It's probably worth stepping back a bit and explaining a bit more what 
you mean by 'ordered' and why that's what you want.  Instructions within 
a basic block that do not have side effects are guaranteed to be 
executed in some order that satisfies their dependencies but there is no 
guarantee within code generation that the order in the IR is preserved.

Once you get to three basic blocks, there's no single execution order of 
basic blocks within the function.  The entry block will be executed 
first, but then the next block to execute depends on the branch 
conditions and some blocks may be executed multiple times.

You can trivially visit all blocks in an undefined order.  You can do a 
breadth-first traversal by looking at the successors found in the 
terminator in every block at a given depth (thought it's a graph, so you 
need to maintain a set of BBs you've visited before), but for any 
non-trivial function that will only very loosely approximate execution 
order.

If you want to track dependencies between invocations of an intrinsic, 
then you might want to consider having that intrinsic return and consume 
a token.  You can then walk def-use chains to get a set of paths through 
the function.

David

On 01/06/2021 03:42, Zhang via llvm-dev wrote:
> Hi:
> 
> In my analysis Pass, I'm trying to visit CallInsts to a special 
> Intrinsic, in the order that they'll be executed, starting from the 
> EntryBlock.
> My naive initial assumption was to start from entryBlock and custom 
> handle Br Instructions, but apparently this doesn't work well with more 
> complicated CFGs like loop or Switch.
> 
> Is there any LLVM builtin infrastructure that could be used for this? 
> Any hint would be appreciated.
> 
> 
> Zhang
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 


More information about the llvm-dev mailing list