[LLVMdev] loop pragmas

[Hal Finkel]

----- Original Message -----
> From: "Krzysztof Parzyszek" <kparzysz at codeaurora.org>
> To: llvmdev at cs.uiuc.edu
> Sent: Tuesday, November 27, 2012 10:58:05 AM
> Subject: Re: [LLVMdev] loop pragmas
> 
> On 11/27/2012 8:03 AM, Hal Finkel wrote:
> >
> > This still leaves the question of exactly how to attach metadata to
> > loops, etc.
> 
> In one implementation, the loops had a fixed structure: guard branch,
> preheader, header and loop body, optional epilog.  The structure was
> clearly identified by various means (flags, bits, etc.).  No
> optimization in the optimizer (roughly a counterpart of the LLVM's
> bitcode optimizer) was allowed to alter it.  For example, CFG
> simplification could change branches all it wanted, *except* the
> branches that were a part of the loop structure.  A "continue" inside
> of
> a loop would not create a nested loop, etc.  This worked like a dream
> (hence my limited appreciation for SimplifyCFG...).
> 
> In that implementation, the metadata was placed in the loop header,
> or
> the loop preheader, depending on what information it was.  Since any
> code that would try to move things around in a loop would have to
> know
> what it's doing (i.e. would have to be aware of the loop structure
> and
> what the rules were), there was no risk that the metadata would
> become
> accidentally separated from the loop.
> 
> I'd love to see something like that in LLVM, help make it happen,
> etc,
> etc.  Of course, other ideas are welcome as well.  :)

Can you please write up a description of exactly what you have in mind? What information would go in the header, preheader (or maybe attached to the backedges, etc.). Would this be metadata or intrinsics (or both)? Would basic-block-level metadata be a better fit? (we had a patch for this proposed some months ago by Ralf Karrenberg -- I just figured I'd mention it in case it is useful here). Obviously we don't want to limit the optimization space available in order to preserve this metadata, and so we need to work out what happens in the case of loop fusion, splitting, etc.

 -Hal

> 
> -Krzysztof
> 
> 
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory