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

[Johannes Doerfert via llvm-dev]

On 01/19, Daniel Berlin via llvm-dev wrote:
> On Thu, Jan 19, 2017 at 1:12 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:
> 
> >
> > On Jan 19, 2017, at 12:04 PM, Daniel Berlin <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> 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
> >
> >
> > 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.
> 
> So it's all tradeoffs.

Right. And while I think the metadata Hal proposed is different (see the
answer by Hal), prior experience (llvm.parallel.loop) tought us that it
takes a lot of effort to keep arbitrary attached metadata up to date and
working well.

> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


-- 

Johannes Doerfert
Researcher / PhD Student

Compiler Design Lab (Prof. Hack)
Saarland Informatics Campus, Germany
Building E1.3, Room 4.31

Tel. +49 (0)681 302-57521 : doerfert at cs.uni-saarland.de
Fax. +49 (0)681 302-3065  : http://www.cdl.uni-saarland.de/people/doerfert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: Digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170120/f93433c5/attachment-0001.sig>