[LLVMdev] Metadata for Argument, BasicBlock

[Dan Gohman]

On May 9, 2012, at 8:28 AM, Ralf Karrenberg wrote:

> On 5/9/12 5:08 PM, Dan Gohman wrote:
>> 
>> On May 8, 2012, at 11:37 PM, Ralf Karrenberg wrote:
>> 
>>> On 5/9/12 2:01 AM, Dan Gohman wrote:
>>>> 
>>>> On May 7, 2012, at 11:11 PM, Ralf Karrenberg<Chareos at gmx.de>   wrote:
>>>> 
>>>>> Hi Dan,
>>>>> 
>>>>> I am using it to store results of a vectorization analysis. A BasicBlock has certain properties in this context, e.g. we mark control flow that may never diverge in different instances ("threads" if you think in terms of CUDA) of the same function by marking the corresponding blocks. This information is later used when linearizing the function (control flow to data flow conversion). I'll be happy to give you more detail on this if you want to :).
>>>> 
>>>> Why are you using metadata to store the results of an analysis?
>>>> LLVM has infrastructure for running analysis passes and making
>>>> their information available to other passes.
>>> 
>>> The analysis is only one way to supply the necessary information to the vectorizer - it could also be generated by a front-end directly. This is a very likely use-case for data-parallel languages that have specific constructs like "uniform"/"varying" (e.g. RenderMan in graphics). Metadata is the perfect thing to store this kind of information.
>> 
>> I'm not a graphics expert, but my understanding of "uniform/varying" is that it's really
>> a property of values, the values which determine which basic blocks are executed, rather
>> than of the basic blocks themselves.  Is that true?
> 
> That is true, sorry for that confusing sentence.
> When vectorizing an entire function to exploit data-level parallelism, normally the whole function is linearized during control-flow to data-flow conversion.
> Our analysis [1] is able to determines cases in which parts of the CFG can be excluded from linearization ("non-divergent" blocks).
> The basis for this is indeed the uniform/varying property of branch conditions, but the criterion is block-specific and thus naturally attaches to basic blocks.
> Also, the block properties influence the uniform/varying property of values (e.g. a phi with uniform incoming values that is in a block where paths from a varying branch join).


A front-end isn't going to do this analysis though. A front-end is just going to know
which user variables are "varying" and which are "uniform".  From your descriptions, it
sounds like your analysis pass is doing all the work thinking about how values, branches,
and phis relate to each other, and it can presumably publish its results to its clients through
the normal Pass communication mechanisms.

Dan