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

James Courtier-Dutton james.dutton at gmail.com
Wed Oct 3 09:30:54 PDT 2012


On 3 October 2012 06:17, Chris Lattner <clattner at apple.com> wrote:
> 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.
>

Would another approach be to work from the bottom up.
Determine the details of what optimizations you wish to be able to do
on a parallel program and then implement functionallity in the LLVM IR
to achieve it.
I.e. A new type of barrier to restrict code motion.
New barrier types, or special zones where only a subset of machine
instructions can be used when lowering.
There are already items in the LLVM IR for atomics, adding a new type
of barrier might be all that is needed to achieve the optimizations
wished for.

Kind Regards

James



More information about the cfe-dev mailing list