[LLVMdev] [cfe-dev] [RFC] Parallelization metadata and intrinsics in LLVM (for OpenMP, etc.)
hfinkel at anl.gov
Tue Oct 2 11:42:47 PDT 2012
On Tue, 2 Oct 2012 10:56:47 -0700
Eric Christopher <echristo at gmail.com> wrote:
> On Mon, Oct 1, 2012 at 9:26 PM, Chris Lattner <clattner at apple.com>
> > On Oct 1, 2012, at 6:16 PM, greened at obbligato.org wrote:
> >> Sanjoy Das <sanjoy at playingwithpointers.com> writes:
> >>> In short, I propose a intrinsic based approach which hinges on the
> >>> concept of a "parallel map". The immediate effect of using
> >>> intrinsics is that we no longer have to worry about missing
> >>> metadata. Moreover, we are still free to lower the intrinsics in
> >>> a variety of ways -- including vectorizing them or lowering them
> >>> to calls to an actual openmp backend.
> >> I'll re-ask here since this is in its own thread.
> >> Why can't we just make ordinary function calls to runtime routines?
> > I agree. I can't imagine any practical way that a metadata-based
> > approach could be preserved by optimizers.
> Yes, this. Absolutely.
I think, in that case, that both you (and Chris) are being somewhat
unimaginative. At this point, I believe that several workable proposals
have been put forward, and what we now need is detailed analysis and
As I've stated, whether the metadata is preserved is not really the
relevant metric. It is fine for a pass that does not understand
parallelization metadata to drop it. The important part is that dropping
the metadata, and moving instructions to which that metadata is
attached, must not cause miscompiles. For example:
- Instructions with unknown side effects or dependencies must not be
moved from outside a parallel region to inside a parallel region.
- Serialized subregions inside of parallel regions cannot be deleted
without deleting the enclosing parallel region.
The outstanding proposals have ways of dealing with these things. In
the case of my proposal, it is though cross-referencing the metadata
sufficiently and using function boundaries to prevent unwanted code
motion. In Intel's case, it is by using the barriers implied by the
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
Leadership Computing Facility
Argonne National Laboratory
More information about the llvm-dev