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

[chuanqi.xcq via cfe-dev]

H John,

> 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

I guess turn coro passes by default could one option. What's your opinion?

Thanks,
Chuanqi
------------------------------------------------------------------
From:John McCall <rjmccall at apple.com>
Send Time:2021年7月9日(星期五) 11:15
To:Mehdi AMINI <joker.eph at gmail.com>
Cc:Xun Li <lxfind at gmail.com>; David Blaikie <dblaikie at gmail.com>; Arthur Eubanks <aeubanks at google.com>; chuanqi.xcq <yedeng.yd at linux.alibaba.com>; cfe-dev <cfe-dev at lists.llvm.org>
Subject:Re: [cfe-dev] Compile .ll file with coroutines intrinsics

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/20210709/3f5f46ae/attachment-0001.html>