[llvm-dev] Multi-Threading Compilers

[Nicholas Krause via llvm-dev]

On 3/26/20 11:56 AM, Nicolai Hähnle via llvm-dev wrote:
> On Thu, Mar 26, 2020 at 12:06 PM Florian Hahn <florian_hahn at apple.com> wrote:
>>> On Mar 26, 2020, at 10:55, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
>>> On Thu, Mar 26, 2020 at 11:53 AM Florian Hahn <florian_hahn at apple.com> wrote:
>>>>> It also doesn't solve the problem of Functions themselves -- those are
>>>>> also GlobalValues…
>>>> I am not sure why not. Function passes should only rely on the information at the callsite & from the declaration IIRC. For functions, we coulkd add extra declarations and update the call sites. But I might be missing something.
>>> Function passes can remove, duplicate, or just plain introduce call
>>> sites (e.g. recognize a memset pattern), which means the use lists of
>>> Functions can be changed during a function pass…
>>
>> Sure, but a single function won’t be processed in parallel by a function pass and would just work on the 'local version' of the globals it uses, including called functions. So a function pass adding/removing calls to existing ‘local versions’ of functions should not be a problem I think.
> Oh, I see what you're saying now. Yes, agreed that that should work.
>
> Though by the time you're done implementing the conversion from and to
> that representation and made sure you've covered all the corner cases,
> I'm not so sure you've really saved a lot of effort relative to just
> doing it right in the first place :)
>
>
>> One problem is that function passes can add new global, e.g. new declarations if they introduce new calls. I guess that would require some locking, but should happen quite infrequently.
> Agreed.
>
> Cheers,
> Nicolai
CCing myself back to the discussion. As to Johannes comments I've not 
problem getting data
but the discussion seems to around implementation and what data we 
actually care about.
That should be discussed first IMO.

Nick
>