[LLVMdev] Loop Metadata?

Sebastian Pop spop at codeaurora.org
Sun Feb 12 10:51:28 PST 2012


On Sat, Feb 11, 2012 at 10:17 AM, Tobias Grosser <tobias at grosser.es> wrote:
> On 02/10/2012 11:29 PM, Sebastian Pop wrote:
>> On Fri, Feb 10, 2012 at 3:53 PM, Devang Patel<dpatel at apple.com>  wrote:
>>> How would you tie a built-in call with a loop ?
>>
>> The same way as Hal was saying: tag the loop header.
>
> So how do we tag the loop header? ;-)
>
> If we just put the instruction in the header, in the worst case LICM
> will move it to header basic block of another loop. :-(

I don't think that optimizers are going to touch a builtin call for which
they don't understand the side effects.  If they do, then they will get
what they deserve: bug reports.

> We could try to keep it somehow attached to the loop. E.g. by making it
> modify a scalar that is changed in each loop iteration. But than again,
> some sophisticated loop fission pass may move these instructions apart.
> We definitely need some conventions for such an approach. Another issue
> is, that as more semantics we put into such a loop marking instruction,
> the more probable it is that we block optimizations like dead code
> elimination of the entire loop. If we do not put any semantics, we may
> risk to loose the annotation.
>
> Another option that I see is somehow in the direction of what Devang
> pointed out. We could make our intention of maintain information about
> the loops more explicit. I could e.g. imagine having some permanent
> pass/analysis, maybe called LoopInformationManager, that is in charge of
> the loop meta data. When reading LLVM-IR it initializes itself by
> reading the loop meta-data. Other passes can call the
> LoopInformationManager for the information they are interested in.
> Passes that do not touch the loop structure need to explicitly specify
> that they preserved the loop semantics. In case this is not done, the
> LoopInformationManager removes the meta-data from the loop. Or in case
> it is informed about a change, it adapts the meta-data accordingly. Such
> that at the end, only valid meta-data will be written out.
> This approach has its own drawbacks, but it may be a direction we could
> consider.

I think that storing information on the side is good for the results of a
program analysis that can be recomputed if the information is lost.
On the other hand, the information that the programmer has put in a
pragma cannot be recomputed, and so in my opinion that should be
part of the IR.

Sebastian
--
Qualcomm Innovation Center, Inc is a member of Code Aurora Forum




More information about the llvm-dev mailing list