[llvm-dev] Parallel IR [PIR] --- BoF preparation discussion

[Kevin Cameron via llvm-dev]

For anyone interested in alternative extensions in the direction HDLs (Verilog, VHDL), I did a prototype extended C++ a while back -

  http://parallel.cc/

There are fairly simple examples here (sync/async life) -

  http://parallel.cc/cgi-bin/bfx.cgi/test_cases.html

It's currently a meta-compiler for g++, but I am intending to migrate it to LLVM if I get the time ;-)

The motivation was partly that the committees that handle HDL standards (IEEE SystemVerilog & VHDL) refused to support an asynchronous-FSM methodology that would work for both hardware and software development, and most of the open-source HDL efforts are some subset of the commercial stuff (and not proper compilers).

The HDL paradigm matches what you need for programming things like neural networks, NUMA/heterogeneous architectures in general, and distributed computing since linkage is done on data-pipes/signals rather than over API/ABI interfaces.

Kev.

On 10/14/2016 03:20 AM, Renato Golin via llvm-dev wrote:
> On 14 October 2016 at 10:38, Johannes Doerfert via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> To structure the mailing list discussion we propose to:
>>   - Inform a broader audience on the (currently) proposed approaches
>>     targeted specifically at LLVM (including but not necessarily limited
>>     to the work by Intel, Dounia Khaldi et al, Tao Schardl et al and our
>>     own work)
>>   - Collect/summarize arguments for and against a "more intrusive"
>>     parallel representation in LLVM.
>>   - Collect/summarize requirements including abstract design goals but
>>     also concrete examples that should (not) be supported.
>>
>> => We will use the summaries to prepare a short presentation for the BoF
>>    (~10min) which allows us to use the majority of time for a qualified
>>    discussion on the topic.
> Hi Johannes,
>
> I think this is a great idea! With a deadline to meet (~2 weeks), and
> a particular focus (feed the BoF discussion), I think we can keep
> ourselves on track.
>
> I particularly welcome a more intrusive change to IR (away from
> metadata) to hold parallelism ideas, since we're past the point where
> SIMD / multi-core was considered only an optimisation, and the
> compiler IR has to evolve to match.
>
> But I'm also worried that we'll end up lost in the multitude of ways
> we can extend the IR. A step by step pragmatic approach is fundamental
> to keep it sane and robust, and I think your starting point conveys
> that well.
>
> We need to make sure we cover simpler cases first, without losing
> sight of the more complicated cases as an evolution of whatever plan
> we come up with. But also, we need to be backward compatible, so that
> the optimisation passes don't start depending solely on the new IR
> constructs to work.
>
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev