llvm dev - Oct 2012 - [LLVMdev] [cfe-dev] [RFC] Parallelization metadata and intrinsics in LLVM (for OpenMP, etc.)

On Mon, Oct 1, 2012 at 9:26 PM, Chris Lattner <clattner at apple.com>
wrote:
>
> 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.

-eric

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>
> wrote:
> >
> > 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
review.

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
intrinsics calls.

 -Hal
> 
> -eric
> _______________________________________________
> 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

Hal Finkel <hfinkel at anl.gov> writes:
> 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
> intrinsics calls.
These two paragraphs seem contradictory to me.  How can a pass rely on
the metadata to not do illegal code motion if the pass has dropped the
metadata?  I must be missing something important.

The only way I can think that this would work is that the explicit
outlining is already done so there is no way to move between
parallel/non-parallel without going all interprocedurally bonkers. :)

This is the kind of thing that worries me about these proposals.

                           -David

On Oct 2, 2012, at 11:42 AM, Hal Finkel <hfinkel at anl.gov>
wrote:
> 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.
I haven't looked at your proposal, but I completely agree in principle that
using procedure boundaries is a good way to handle this.
> In Intel's case, it is by using the barriers implied by the
> intrinsics calls.
That's just it - intrinsics using metadata don't imply barriers that
would restrict code motion.

-Chris