Page MenuHomePhabricator

Introduce -fembed-bitcode driver option

Authored by steven_wu on Feb 18 2016, 9:38 AM.



This is the clang driver part of the change to embedded bitcode. This

  1. -fembed-bitcode option which breaks down the compilation into two

stages. The first stage emits optimized bitcode and the second stage
compiles bitcode into object file.

  1. -fembed-bitcode-marker option which doesn't really break down to

two stages to speedup the compilation flow.

  1. pass the correct linker flag to darwin linker if tool chains supports

embedded bitcode.

Diff Detail


Event Timeline

steven_wu updated this revision to Diff 48345.Feb 18 2016, 9:38 AM
steven_wu retitled this revision from to Introduce -fembed-bitcode driver option.
steven_wu updated this object.
steven_wu added a subscriber: cfe-commits.

I don't understand the changes to Driver.cpp lines 1760 and down. The rest looks good to me.

1761 ↗(On Diff #48345)

Why is this change needed? If its needed, is the preceding comment out of date now?

steven_wu updated this revision to Diff 49431.Feb 29 2016, 3:46 PM

Make selectToolForJob logic better and less disruptive for -fembed-bitcode.

When -fembed-bitcode is used, the same old logic is used to decide if
CompileJob and BackendJob can be combined with an extra requirement for
-fembed-bitcode. The old logic was there to work around the Fortran input
which invokes gcc to compile. -fembed-bitcode requires CompileJob and BackendJob
to be the same (and can emit IR) so it can be splited between these two stages.

thakis accepted this revision.Feb 29 2016, 4:38 PM
thakis added a reviewer: thakis.

Thanks, that's much clearer :-)

This revision is now accepted and ready to land.Feb 29 2016, 4:38 PM
This revision was automatically updated to reflect the committed changes.

Thanks for reviewing the patch. There is a problem in the test case (it only works on darwin). It is fixed in r262286.

1761 ↗(On Diff #48345)

The preceding comment is still true but this condition makes BackendInputs->begin() not always CompileJobAction. I have a cleaner way to handle this. I am rebasing and updating the patch.