[cfe-dev] Compile .ll file with coroutines intrinsics

[John McCall via cfe-dev]

On 8 Jul 2021, at 22:01, Mehdi AMINI wrote:
> On Thu, Jul 8, 2021 at 6:56 PM John McCall <rjmccall at apple.com> wrote:
>> On 8 Jul 2021, at 20:13, Mehdi AMINI wrote:
>>> On Thu, Jul 8, 2021 at 4:40 PM Xun Li <lxfind at gmail.com> wrote:
>>>
>>>> Not sure if I fully understand the question. Do you have a full
>>>> example of what you expect but doesn't work?
>>>> Are you trying to compile C++ code that uses coroutines, or are you
>>>> trying to use opt to compile an .ll file?
>>>>
>>>
>>> I'm trying to compile IR (.ll or .bc) file: clang support IR as 
>>> *input*
>> as
>>> well.
>>>
>>> So for example with the case you mention:
>>>
>>> clang -emit-llvm  -c    -O3  -Xclang -disable-llvm-passes
>>> clang/test/CodeGenCoroutines/coro-symmetric-transfer-01.cpp 
>>> -std=c++20 -o
>>> coro.bc
>>>
>>> This gets me a nice coro.bc file, but I have no way to compile this 
>>> with
>>> clang right now, it will always crash:
>>>
>>> $ clang -c coro.bc
>>> PLEASE submit a bug report to https://bugs.llvm.org/ and include the
>> crash
>>> backtrace, preprocessed source, and associated run script.
>>> Stack dump:
>>> 0. Program arguments: clang -c coro.bc
>>> 1. Code generation
>>> 2. Running pass 'Function Pass Manager' on module 'coro.bc'.
>>> 3. Running pass 'X86 DAG->DAG Instruction Selection' on function
>> '@_Z3foov'
>>> Segmentation fault
>>
>> Coroutines do push the boundaries of LLVM IR in the sense that
>> (1) there’s a mandatory lowering sequence and (2) because of the
>> complexity of that lowering, the IR prior to that sequence is
>> much more of an internal representation than a stable format.
>> With that said, I don’t know of any inherent reason why running
>> the coroutine passes multiple times would be a problem.  It’s
>> probably just some bit of coroutine bookkeeping (the attribute?)
>> that we fail to remove after lowering.
>>
>> Also, the exact form of the crash is surprising; I don’t know
>> why running lowering multiple times would add new things that
>> ISel wouldn’t recognize.
>>
>
> Right now this isn't running it multiple times, it is instead never 
> running
> it, the backend crashes because ISel does not know about these 
> intrinsics

Ah, I had the opposite problem on my mind, sorry.

> (I think we should be friendlier in the failure mode, but that's 
> another
> story).

Yes, that’s tricky because, again, LLVM doesn’t like to admit that
mandatory lowering is a thing outside of the codegen prepare passes.
Ideally we’d be able to say that IR in a certain stage never has
certain properties, but we lack the concept of stages.

> I use clang to emit IR without running any pass (this is the ` -Xclang
> -disable-llvm-passes` part of the invocation).
>
>  Then I'd like to use clang to "resume" compilation of this file, but 
> clang
> does not allow me to have an IR input file and run these passes: this 
> is
> what I'd like to fix. One option I had in the original email in this 
> thread
> was to change clang to honor `-fcoroutines-ts` when the input is an IR 
> file.

Given what I said above about stages, I think clang’s current behavior
of producing fully-lowered IR from `-emit-llvm` and then expecting
`.ll`/`.bc` inputs to be fully-lowered IR is the right default.
Probably what we need is a way to override this, which build systems
would expect to be properly paired with `-disable-llvm-passes`.
So with that option we’d build exactly the same pipeline as we
would for a source invocation.

Alternatively, we could write something about the expected pipeline
into the IR file.  I don’t know if we build the pipeline before
the initial load of the module.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210708/a873ce54/attachment.html>