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

[Daniel Berlin via llvm-dev]

On Thu, Jan 19, 2017 at 11:46 AM, Mehdi Amini via llvm-dev <
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> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170119/b8ef48a0/attachment.html>