[llvm-dev] llvm-dev Digest, Vol 145, Issue 105

Thu Jul 21 12:14:47 PDT 2016

Peter Zion
Fabric Engine
  Original Message  
From: via llvm-dev
Sent: Thursday, July 21, 2016 3:00 PM
To: llvm-dev at lists.llvm.org
Reply To: llvm-dev at lists.llvm.org
Subject: llvm-dev Digest, Vol 145, Issue 105

Send llvm-dev mailing list submissions to
llvm-dev at lists.llvm.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
or, via email, send a message with subject or body 'help' to
llvm-dev-request at lists.llvm.org

You can reach the person managing the list at
llvm-dev-owner at lists.llvm.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of llvm-dev digest..."

Today's Topics:

1. Re: [RFC] One or many git repositories?
(Justin Lebar via llvm-dev)
2. Re: RFC: LLVM Coroutine Representation, Round 2
(Gor Nishanov via llvm-dev)
3. Re: RFC: Strong GC References in LLVM (Philip Reames via llvm-dev)

----------------------------------------------------------------------

Message: 1
Date: Thu, 21 Jul 2016 11:20:01 -0700
From: Justin Lebar via llvm-dev <llvm-dev at lists.llvm.org>
To: Sanjoy Das <sanjoy at playingwithpointers.com>
Cc: Justin Lebar via llvm-dev <llvm-dev at lists.llvm.org>, Jonathan
Roelofs <jonathan at codesourcery.com>
Subject: Re: [llvm-dev] [RFC] One or many git repositories?
Message-ID:
<CAMuNMfqDxMYbHXnkffyaKVqELUtbVjgfgia-deuEJAeY8akTQw at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

> What do people think of having one (or a set of) merge commit(s)
> merging in the non-llvm projects that will be part of the new
> monorepo? That's the only technique I can think of that will preserve
> history for downstream users by construction.

This would solve the problem of importing history. But if we did it
this way, you'd be unable to check out versions of the complete repo
from before the merge date. So you'd be unable to bisect back before
the merge date, for example. I think the umbrella repo might be a
better solution than one which had that property.

I don't know if there's a way to allow checkouts of everything from
before the merge date while also making the custom branch merge to the
monolithic repository as trivial as "git merge". I think it may
depend on git's handling of file renames, and if so...I am not too
hopeful. :)

For at least David's branches, I think it would be really cool if we
could merge the llvm and clang branches into a single branch with
correct history. We wouldn't be able to do that if we used git merge
to build the monorepo out of its constituent pieces.

On Thu, Jul 21, 2016 at 11:03 AM, Sanjoy Das via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> FWIW, like David Chisnall, we (Azul) have a problem with rewriting
> history. Our LLVM fork has O(100) changes diverging from upstream
> (though our branching structure is simple), and keeping all of that
> history is important.
>
> What do people think of having one (or a set of) merge commit(s)
> merging in the non-llvm projects that will be part of the new
> monorepo? That's the only technique I can think of that will preserve
> history for downstream users by construction.
>
> -- Sanjoy
>
>
> On Thu, Jul 21, 2016 at 10:44 AM, Jonathan Roelofs via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>>
>>
>> On 7/21/16 11:03 AM, C Bergström via llvm-dev wrote:
>>>
>>> Monolithic is trying to solve the wrong problem - it's that simple.
>>> Any discussion or attempt to coddle those who think it's necessary is
>>> a waste of time. #dictator
>>
>>
>> Christopher,
>>
>> AFAICT, you haven't explained *why* it is the wrong problem. Mind
>> elaborating on that?
>>
>>
>> Jon
>>
>> p.s: edicts, appeals to authority, and ad hominems are not useful for
>> discussion. Doing that, and following up with "#dictator" further solidifies
>> that you know your own argument is b-s.... please stop.
>>
>> --
>> Jon Roelofs
>> jonathan at codesourcery.com
>> CodeSourcery / Mentor Embedded
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> --
> Sanjoy Das
> http://playingwithpointers.com
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

------------------------------

Message: 2
Date: Thu, 21 Jul 2016 11:43:44 -0700
From: Gor Nishanov via llvm-dev <llvm-dev at lists.llvm.org>
To: Vadim Chugunov <vadimcn at gmail.com>
Cc: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] RFC: LLVM Coroutine Representation, Round 2
Message-ID:
<CAJ4Vuxs7ivNMGT6UDJ14AjGgJzVYDDOLPRYZ4nuwJ8SovE2w3A at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Hi Vadim:

> Does you design support resumption with parameter(s)? (such as Python's
> generator.send(x)). I suppose the "promise" could be used for passing data
> both ways,

Correct.

The docs/Coroutines.rst states that:

"A coroutine author or a frontend may designate a distinguished `alloca`
that can be used to communicate with the coroutine."

What kind of communication happens is determined by the source language
coroutine constructs. An example later in the section shows how, as a consumer
of a coroutine, you can read the data from the promise. But that communication
can go the other way if you, instead, will be storing into the promise in main,
and loading from it in the coroutine.

coro.promise intrinsic gives you the address of the promise associated with a
particular coroutine instance and you (as frontend writer, or coroutine library
designer is free to do whatever you want with it).

> please mention this explicitly in the design doc.

Would you suggest changes to the exact wording to make it clearer? I put it up
for review at: https://reviews.llvm.org/D22603, so you can just mark up the
changes you would like to see.

> Also, how is loading/storing to promise going to be lowered?

The coro.promise intrinsics just gives you an address of the coroutine promise.
You, as frontend / library writer, know what is the promise and you emit
appropriate load or stores instructions.

If you have a synchronous scenario and a promise is plain int, you would use
plain loads and stores. If your promise is some complicated data structure
which has atomics and you use it from different threads, you would use
appropriate loads, stores, fences and synchronization primitives.

But all this is out of scope for docs/Coroutines.rst . It is up to the frontend,
library writer to decide how it wants to use the promise. The only special
handling that LLVM does for the coroutine promise is:

1) places the promise at deterministic offset in the coroutine frame
2) allows you to get an address of the promise given a coroutine handle and
vice versa.

Cheers,
Gor

P.S. If you'd like to see a library implementation of a generator, please see:

Generator itself:
https://github.com/GorNishanov/clang/blob/coro-rfc/test/Coroutines/Inputs/generator.h

coroutine_handle (a C++ level abstraction mapping to llvm intrinsics)
https://github.com/GorNishanov/clang/blob/coro-rfc/test/Coroutines/Inputs/coroutine.h

and the use:

https://github.com/GorNishanov/clang/blob/coro-rfc/test/Coroutines/generator.cpp

Well, if start looking at those tests, you may enjoy coroutines in C via macros,
lowered to the same coroutine intrinsics :-).

https://github.com/GorNishanov/clang/blob/coro-rfc/test/Coroutines/coro.c

and

https://github.com/GorNishanov/clang/blob/coro-rfc/test/Coroutines/Inputs/coro.h

------------------------------

Message: 3
Date: Thu, 21 Jul 2016 11:59:33 -0700
From: Philip Reames via llvm-dev <llvm-dev at lists.llvm.org>
To: Daniel Berlin <dberlin at dberlin.org>, Andrew Trick
<atrick at apple.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>, Oscar Blumberg
<oscar.blumberg at normalesup.org>
Subject: Re: [llvm-dev] RFC: Strong GC References in LLVM
Message-ID: <57911B95.4050409 at philipreames.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

On 07/21/2016 10:30 AM, Daniel Berlin wrote:
>
>
> On Thu, Jul 21, 2016 at 9:39 AM, Daniel Berlin <dberlin at dberlin.org 
> <mailto:dberlin at dberlin.org>> wrote:
>
>
>
> On Thu, Jul 21, 2016 at 9:26 AM, Andrew Trick <atrick at apple.com
> <mailto:atrick at apple.com>> wrote:
>
>
>> On Jul 21, 2016, at 7:45 AM, Philip Reames
>> <listmail at philipreames.com
>> <mailto:listmail at philipreames.com>> wrote:
>>
>> Joining in very late, but the tangent here has been
>> interesting (if rather OT for the original thread).
>>
>> I agree with Danny that we might want to take a close look at
>> how we model things like maythrow calls, no return, and other
>> implicit control flow. I'm not convinced that moving to a
>> pure explicit model is the right idea because we get a lot of
>> gain in practice from being able to reason about what are
>> essentially a limited form of extended basic blocks. I would
>> welcome a design discussion about this, preferably in person,
>> but also don't want to block any current (or future honestly)
>> work on this until we have a reasonable firm plan of action.
>>
>> One idea would be to explicitly acknowledge that our "basic
>> blocks" are actually "extended basic blocks" with internal
>> exits due to exception propagation, noreturn, and (recently)
>> guards. I could see a couple of implementation strategies here:
>> 1) Extend BasicBlock to explicitly track potential early
>> exiting instructions. This would probably have to be
>> conservative so that things like nothrow inference aren't
>> required to update all callers in one go.
>> 2) Conservative assume that BasicBlock has an unknown number
>> of early exiting instructions and write an analysis pass
>> which answers questions about where those early exits are. 
>> Any pass which does code motion would require this analysis.
>> (This is essentially the principled version of our current
>> hacks.)
>
> This analysis can be lazy/incremental. Most passes only do
> “safe” speculation and code sinking without side effects.
>
>
> While I agree it can be lazy, and should be an analysis, i'm,
> again, really not sure which passes you are thinking about here
> that do code sinking/speculation that won't need it.
>
> Here's the list definitely needing it right now:
> GVN
> GVNHoist
> LICM
> LoadCombine
> LoopReroll
> LoopUnswitch
> LoopVersioningLICM
> MemCpyOptimizer
> MergedLoadStoreMotion
> Sink
>
> The list is almost certainly larger than this, this was a pretty
> trivial grep and examination.
> (and doesn't take into account bugs, etc)
>
>
>
> (Note, this list is stuff in the Scalar directory only. Everything in 
> Vectorize would n eed it, etc)
>
> And in case folks want more evidence that reasonable llvm developers 
> need something that just gives easy and right answers, see 
> https://reviews.llvm.org/D22547 from just yesterday :)
>
> To move this along, i will go build the analysis (I already have it 
> mostly done, actually). If someone updates our docs to make this 
> stuff clear and obvious, that would be wonderful :)
>
> The analysis currently computes, internally, for a given BB:
>
> EarliestLoadHoistBarrier (used to see if you can move something out of 
> a block)
> LatestLoadHoistBarrier (used to find the latest safe insertion point 
> in a block, if any)
> EarliestStoreSinkBarrier (insertion)
> LatestStoreSinkBarrier (movement)
>
>
> (stores are maythrow dependent, loads are 
> isGuaranteedToTransferExecutionToSuccessor dependent)
>
> I'm still coming up with the external API, the users all want to know 
> either:
>
> 1. Can i move a load up out of this block to a direct predecessor
> 2. Can i move a store down out of this block to a direct successor
I would argue that we should have this analysis *only* report the EBB 
information. Doing this in the form of the information you've mentioned 
is fine, but I would not want to see this become our deref analysis for 
instance. I think that needs to be a separate analysis which is well 
layered on top of this one. (i.e. once I encounter a hoist barrier, I 
need to then ask if a load is safe to speculate beyond that point as a 
separate question.)
>
> GVN's current load PRE is complex to get "right" from it's current 
> standpoint, the APi that will provide the easiest way to fix it will be:
>
> 3. What is the latest insertion point in a block for a load, if it is 
> safe (IE the block does not end in an instruction you cannot move the 
> load before).
>
> Nothing is doing global store sinking right now that i see, so nothing 
> needs the analogous store api.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160721/6be95187/attachment-0001.html>

------------------------------

Subject: Digest Footer

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

------------------------------

End of llvm-dev Digest, Vol 145, Issue 105
******************************************