[llvm-dev] [RFC] IR-level Region Annotations
Hal Finkel via llvm-dev
llvm-dev at lists.llvm.org
Thu Jan 19 20:28:57 PST 2017
On 01/19/2017 03:36 PM, Mehdi Amini via llvm-dev wrote:
>> On Jan 19, 2017, at 1:32 PM, Daniel Berlin <dberlin at dberlin.org
>> <mailto:dberlin at dberlin.org>> wrote:
>> On Thu, Jan 19, 2017 at 1:12 PM, Mehdi Amini<mehdi.amini at apple.com
>> <mailto:mehdi.amini at apple.com>>wrote:
>>> On Jan 19, 2017, at 12:04 PM, Daniel Berlin <dberlin at dberlin.org
>>> <mailto:dberlin at dberlin.org>> wrote:
>>> On Thu, Jan 19, 2017 at 11:46 AM, Mehdi Amini via
>>> llvm-dev<llvm-dev at lists.llvm.org
>>> <mailto:llvm-dev at lists.llvm.org>>wrote:
>>> > On Jan 19, 2017, at 11:36 AM, Adve, Vikram Sadanand via
>>> llvm-dev <llvm-dev at lists.llvm.org
>>> <mailto:llvm-dev at lists.llvm.org>> wrote:
>>> > Hi Johannes,
>>> >> I am especially curious where you get your data from.
>>> Tapir  (and to
>>> >> some degree PIR ) have shown that, counterintuitively,
>>> only a few changes
>>> >> to LLVM passes are needed. Tapir was recently used in an
>>> MIT class with a
>>> >> lot of students and it seemed to work well with only
>>> minimal changes
>>> >> to analysis and especially transformation passes.
>>> > TAPIR is an elegant, small extension and, in particular, I
>>> think the idea of asymmetric parallel tasks and control flow
>>> is a clever way to express parallelism with serial
>>> semantics, as in Cilk. Encoding the control flow extensions
>>> as explicit instructions is orthogonal to that, though
>>> arguably more elegant than using region tags + metadata.
>>> > However, Cilk is a tiny language compared with the full
>>> complexity of other languages, like OpenMP. To take just
>>> one example, TAPIR cannot express the ORDERED construct of
>>> OpenMP. A more serious concern, IMO, is that TAPIR (like
>>> Cilk) requires serial semantics, whereas there are many
>>> parallel languages, OpenMP included, that do not obey that
>>> restriction. Third, OpenMP has *numerous* clauses, e.g.,
>>> REDUCTION or PRIVATE, that are needed because without that,
>>> you’d be dependent on fundamentally hard compiler analyses
>>> to extract the same information for satisfactory parallel
>>> performance; realistic applications cannot depend on the
>>> success of such analyses.
>>> I agree with this, but I’m also wondering if it needs to be
>>> first class in the IR?
>>> For example we know our alias analysis is very basic, and
>>> C/C++ have a higher constraint thanks to their type system,
>>> but we didn’t inject this higher level information that
>>> helps the optimizer as first class IR constructs.
>>> FWIW, while i agree with the general point, i wouldn't use this
>>> Because we pretty much still suffer to this day because of it
>>> (both in AA, and devirt, and ...) :)
>>> We can't always even tell fields apart
>> Is it inherent to the infrastructure, i.e. using metadata instead
>> of first class IR construct or is it just a “quality of
>> implementation” issue?
>> Not to derail this conversation:
>> IMHO, At some point there is no real difference :)
>> Because otherwise, everything is a QOI issue.
>> IE if it's super tricky to get metadata that works well and works
>> right, doesn't get lost, etc, and that's inherent to using metadata,
>> that to me is not a QOI issue.
>> So could it be done with metadata? Probably?
>> But at the same time, if it had been done with more first class
>> constructs, it would have happened years ago and been much lower cost.
> This is what I meant by “inherent to the infrastructure”, thanks for
To clarify, we were proposing metadata that is used as arguments to the
region-annotation intrinsics. This metadata has the nice property that
it does not get dropped (so it is just being used as a way of encoding
whatever data structures are necessary without predefining a syntactic
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev