[clang]Test ensuring -fembed-bitcode passed to cc1 captures pre-opt bitcode.

[mtrofin]

Summary

This is important to not regress because it allows us to capture pre-optimization
bitcode and options, and replay the full optimization pipeline.

[steven_wu]

I am not sure what exactly is expected here. What is your definition for pre-optimized bitcode and how your test case ensures that? Can you explain a bit more for context?

[mtrofin]

In D88114#2288732, @steven_wu wrote:

I am not sure what exactly is expected here. What is your definition for pre-optimized bitcode and how your test case ensures that? Can you explain a bit more for context?

Pre-optimized meaning before the llvm optimization pipeline is called. That's the current implementation, and the test explicitly checks that the inlining of bar into foo doesn't happen.

I could add an "alwaysinline" to bar, to further stress that.

[steven_wu]

In D88114#2288737, @mtrofin wrote:

In D88114#2288732, @steven_wu wrote:

I am not sure what exactly is expected here. What is your definition for pre-optimized bitcode and how your test case ensures that? Can you explain a bit more for context?

Pre-optimized meaning before the llvm optimization pipeline is called. That's the current implementation, and the test explicitly checks that the inlining of bar into foo doesn't happen.

I could add an "alwaysinline" to bar, to further stress that.

I think the current implementation does run optimization passes if the input is c family language and we need to keep it that way (just so that we don't do most of the optimization again). The reason you don't see it running because you are using IR as input. For Apple's implementation, we actually pass -disable-llvm-passes when the input is IR to ensure no optimization passes are running.

[mtrofin]

In D88114#2288749, @steven_wu wrote:

In D88114#2288737, @mtrofin wrote:

In D88114#2288732, @steven_wu wrote:

I am not sure what exactly is expected here. What is your definition for pre-optimized bitcode and how your test case ensures that? Can you explain a bit more for context?

Pre-optimized meaning before the llvm optimization pipeline is called. That's the current implementation, and the test explicitly checks that the inlining of bar into foo doesn't happen.

I could add an "alwaysinline" to bar, to further stress that.

I think the current implementation does run optimization passes if the input is c family language and we need to keep it that way (just so that we don't do most of the optimization again). The reason you don't see it running because you are using IR as input. For Apple's implementation, we actually pass -disable-llvm-passes when the input is IR to ensure no optimization passes are running.

Afaik, today's implementation has 2 parts: driver and cc1. The cc1 part always emits before opt passes. The driver part, upon seeing -fembed-bitcode, splits compilation in 2 stages. Stage 1 performs ops and emits bc to a file (-emit-llvm). Stage 1 doesn't expose -fembed-bitcode to cc1. Stage 2 takes the output from stage1, disables optimizations, and adds -fembed-bitcode. So together, this gives the semantics you mentioned, but it happens that if you skip the driver and pass -fembed-bitcode to cc1, we get the pre-opt bitcode, which helps my scenario.

[steven_wu]

Ok, I guess we are on the same page. The idea sounds fine to me.

I would suggest just check that the output matches the input file as much as possible, rather than just check a label and a call instruction.

[mtrofin]

Added a C test, strenghtened the checks

[mtrofin]

In D88114#2288860, @steven_wu wrote:

Ok, I guess we are on the same page. The idea sounds fine to me.

I would suggest just check that the output matches the input file as much as possible, rather than just check a label and a call instruction.

Makes sense - also added a C test, same idea.

[mtrofin]

newline at end of file

[steven_wu]

LGTM

clang/test/Frontend/embed-bitcode-noopt.c

+// Ensure calling bypassing the driver with -fembed-bitcode embeds bitcode pre-
+// optimizations
+// REQUIRES: x86-registered-target
+// RUN: %clang_cc1 %s -O2 -emit-obj -triple=x86_64-unknown-linux-gnu -o %t.o -fembed-bitcode=all
+// RUN: llvm-objcopy --dump-section=.llvmbc=%t.bc %t.o /dev/null
+
+// Also check that the .llvmcmd section captures the optimization options.
+// RUN: llvm-dis %t.bc -o - | FileCheck %s --check-prefix=CHECK-BC
+// RUN: llvm-objcopy --dump-section=.llvmcmd=- %t.o /dev/null | FileCheck %s --check-prefix=CHECK-CMD
+
+// CHECK-BC-LABEL: define void @bar() #0 {
+// CHECK-BC-NEXT: entry:
+// CHECK-BC-NEXT: ret void
+// CHECK-BC-NEXT: }
+// CHECK-BC-LABEL: define void @foo() #1 {
+// CHECK-BC-NEXT: entry:
+// CHECK-BC-NEXT: call void @bar()
+// CHECK-BC-NEXT: ret void
+// CHECK-BC-NEXT: }
+// CHECK-BC-LABEL: attributes #0 = {{.*}} alwaysinline
+// CHECK-CMD: -O2
+
+__attribute__((always_inline)) void bar() {
+  return;
+}
+
+void foo() {
+  bar();
+  return;
+}

clang/test/Frontend/embed-bitcode-noopt.ll

+; Ensure calling bypassing the driver with -fembed-bitcode embeds bitcode pre-
+; optimizations
+
+; RUN: %clang_cc1 -O2 -triple x86_64-unknown-linux-gnu -emit-obj %s -o %t.o -fembed-bitcode=all
+; RUN: llvm-objcopy --dump-section=.llvmbc=%t.bc %t.o /dev/null
+
+; Also check that the .llvmcmd section captures the optimization options.
+; RUN: llvm-dis %t.bc -o - | FileCheck %s --check-prefix=CHECK-BC
+; RUN: llvm-objcopy --dump-section=.llvmcmd=- %t.o /dev/null | FileCheck %s --check-prefix=CHECK-CMD
+
+; CHECK-BC-LABEL: define void @bar() #0 {
+; CHECK-BC-NEXT:  ret void  
+; CHECK-BC-NEXT: }
+; CHECK-BC-LABEL: define void @foo() {
+; CHECK-BC-NEXT: call void @bar()
+; CHECK-BC-NEXT: ret void
+; CHECK-BC-NEXT: }
+; CHECK-BC-LABEL: attributes #0 = { alwaysinline }
+; CHECK-CMD: -O2
+
+define void @bar() #0 {
+    ret void
+}
+
+define void @foo() {
+  call void @bar()
+  ret void
+}
+
+attributes #0 = { alwaysinline }