[llvm-dev] [RFC] IR-level Region Annotations

Mehdi Amini via llvm-dev
Thu, 19 Jan 2017 21:36:32 -0000

> On Jan 19, 2017, at 1:32 PM, Daniel Berlin <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
[0] (and to
>> >> some degree PIR [1]) 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
example.
>> 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 clarifying.

—
Mehdi


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170119/3cc91066/attachment.html>