[llvm-dev] [GlobalISel] Questions about selection regions
Bekket McClane via llvm-dev
llvm-dev at lists.llvm.org
Tue Jan 31 17:32:54 PST 2017
> Ahmed Bougacha <ahmed.bougacha at gmail.com> 於 2017年2月1日 上午2:11 寫道：
> On Tue, Jan 31, 2017 at 7:12 AM, Bekket McClane via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> I've been studying the global instruction selector introduced recently. One
>> of the properties of global instruction selectors is that they select
>> instructions across basic blocks such that they can get more information in
>> order to choose optimal patterns.
>> However, the current global isel implementation still iterates over BBs
>> within functions, which is same as the original SelectionDAG approach, and
>> select individual instruction without "peeking" the information of other
>> basic blocks. IMOO, neither do the overall design nor the individual
>> instruction selector routines take the "global information" into concern.
>> Are my observations correct?
> It iterates over instructions (within blocks within functions) because
> instructions are the "roots" of the selector logic. When examining a
> root, the selector is free to examine the instructions defining the
> operands of the root; these might be in different basic blocks.
> Put another way, the difference between SelectionDAG and GlobalISel is
> that the SelectionDAG selector logic can only access instructions
> contained in the parent of the root instruction (because at any given
> time, that's the only block that we created a DAG for).
> In GlobalISel, the entire function is accessible, so the selector can
> consume instructions even if they are not in the same block as the
> root instruction. It's in that sense that GlobalISel is "global”.
I think I got the point.
Thank you very much: )
>> Also, are there any examples which show that the current global isel take
>> information across multiple BBs within a function?
> I don't think any of the targets use this feature right now. The
> first use will probably be folding of G_CONSTANT nodes (that we
> currently all emit in the entry block) into immediate operands.
>> Best Regards,
>> Bekket McClane
>> Department of Computer Science,
>> National Tsing Hua University
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
More information about the llvm-dev