aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/cpp/FdoSupport.java
Commit message (Collapse)AuthorAge
* Remove LIPO supportGravatar hlopko2018-06-15
| | | | | RELNOTES: Support for LIPO has been fully removed. PiperOrigin-RevId: 200724578
* Refactoring: makes the code simpler by deleting Metadata and InputArtifactData.Gravatar shahan2018-06-06
| | | | | | (minor) ActionFS now implements MetadataProvider.getInput PiperOrigin-RevId: 199575194
* Build support for enabling cross binary FDO optimization.Gravatar Googler2018-06-06
| | | | | | | Crossbinary FDO optimization is a special form of AutoFDO which uses a synthetic profile to optimize targets without any profile. The synthetic profile will often be used as a default profile and will use .xfdo as suffix. It will be passed though option -fdo_optimize just like Autofdo profile. If .xfdo file is passed through -fdo_optimize in the same command line with other types of profiles, .xfdo file will be neglected. RELNOTES: Build support for enabling cross binary FDO optimization. PiperOrigin-RevId: 199501260
* Build support for passing a software cache prefetching hints file.Gravatar Googler2018-05-16
| | | | | | | | | This flag assumes llvm supports an experimental 'prefetch-hints-flag' flag. The Bazel support simply plumbs the provided file through to the compiler. The flag is independent from the other fdo_ flags, and may be applied in any combination with them. RELNOTES: Introduce build support for providing cache prefetch hints. PiperOrigin-RevId: 196916547
* Extract logic for dealing with CROSSTOOL values and build variables into ↵Gravatar rosica2018-05-14
| | | | | | | separate class RELNOTES: None. PiperOrigin-RevId: 196517537
* C++: Renames CcCompilationContextInfo to CcCompilationContextGravatar plf2018-05-14
| | | | | | | Since it's not a provider, it doesn't need the Info suffix anymore. RELNOTES:none PiperOrigin-RevId: 196498526
* Make --fdo_optimize paths be PathFragment instead of Path, and remove the ↵Gravatar Googler2018-04-11
| | | | | | now unused ConfigurationEnvironment#getBlazeDirectories() PiperOrigin-RevId: 192443323
* C++: Rename CcCompilationInfo to CcCompilationContextInfo.Gravatar plf2018-04-03
| | | | | | | | | This is done so that the name CcCompilationInfo can be used for the C++ provider that will wrap all providers for compilation, similar to JavaInfo in Java. RELNOTES:none PiperOrigin-RevId: 191445120
* Move strip and compile build variables into separate classesGravatar hlopko2018-03-28
| | | | | | | | Working on link build variables I see they cannot stay in a single file, they're too big and complicated. This will make the followup cl smaller. RELNOTES: None. PiperOrigin-RevId: 190771072
* Isolate C++ compile build variablesGravatar hlopko2018-03-27
| | | | | | | | | | | | | | This is a preparation work to expose Variables instance for all compile actions to Skylark. I didn't do linking variables in this cl, because this cl is already too big. But they're coming shortly in a separate cl. This is also in line with our goal to make build variables more discoverable and better document. RELNOTES: None. PiperOrigin-RevId: 190591080
* Make FdoSupport use outputName to generate object file pathGravatar pcloudy2018-03-20
| | | | | | | | | | Object file path will no longer be derived from source file path directly. This is a preparation change for[] Related issue https://github.com/bazelbuild/bazel/issues/4149 RELNOTES: None PiperOrigin-RevId: 189722421
* PiperOrigin-RevId: 189372237Gravatar Googler2018-03-16
|
* Tags some more non-serializable classes (for serialization).Gravatar shahan2018-03-13
| | | | PiperOrigin-RevId: 188930446
* C++: Renames CppCompilationContext to CcCompilationInfoGravatar plf2018-02-21
| | | | | | | This is in preparation for migrating to the new way of specifying providers as described in[] RELNOTES:none PiperOrigin-RevId: 186436462
* Route fdo logic that deals with the path to the fdo profile through ↵Gravatar Googler2018-02-20
| | | | | | | | | | CcToolchainProvider As --fdo_optimize can point to a label, the path to the fdo profile can not be reliably determined in CppConfiguration. In order to enable the fdo features (which depend on the path to the fdo profile), the logic from CppConfiguration.configurationEnabledFeatures() has been moved to CcCommon.configureFeatures(). The latter method has access to the fdo profile path through CcToolchainProvider. RELNOTES: None. PiperOrigin-RevId: 186278311
* Add @AutoCodec for FdoSupport(Provider) and TemplateVariableInfo.Gravatar mjhalupka2018-02-16
| | | | PiperOrigin-RevId: 186007056
* Introduce Root class.Gravatar tomlu2018-01-17
| | | | | | | | | | | This class represents a root (such as a package path or an output root) used for file lookups and artifacts. It is meant to be as opaque as possible in order to hide the user's environment from sky keys and sky functions. Roots are used by RootedPaths and ArtifactRoots. This CL attempts to make the minimum number of modifications necessary to change RootedPath and ArtifactRoot to use these fields. Deprecated methods and invasive accessors are permitted to minimise the risk of any observable changes. RELNOTES: None PiperOrigin-RevId: 182271759
* Rename Root to ArtifactRoot.Gravatar tomlu2018-01-16
| | | | | | This is slightly more descriptive, and we will potentially want to use the name Root for a broader concept shared between ArtifactRoot and RootedPath. PiperOrigin-RevId: 182082367
* Remove isMainRepo from Root.Gravatar tomlu2018-01-12
| | | | | | This is no longer used. PiperOrigin-RevId: 181754475
* Move CppConfiguration#isLLVMcompiler, #isLLVMOptimizedFdo, #isLipoOptimization,Gravatar cpeyser2017-11-22
| | | | | | | | | and #getDynamicMode to CcToolchainProvider and CppHelper. Moving toolchain info out of CppConfiguration is required to use platform-based toolchain resolution in the c++ rules. PiperOrigin-RevId: 176662686
* Replace all usages of Blaze's Preconditions class with guava.Gravatar tomlu2017-11-09
| | | | | | | | Blaze had its own class to avoid GC from varargs array creation for the precondition happy path. Guava now (mostly) implements these, making it unnecessary to maintain our own. This change was almost entirely automated by search-and-replace. A few BUILD files needed fixing up since I removed an export of preconditions from lib:util, which was all done by add_deps. There was one incorrect usage of Preconditions that was caught by error prone (which checks Guava's version of Preconditions) that I had to change manually. PiperOrigin-RevId: 175033526
* Make Fdo use straight zip files, delete ZipFileSystem.Gravatar tomlu2017-10-06
| | | | PiperOrigin-RevId: 171221156
* Remove product name precomputed value.Gravatar janakr2017-09-25
| | | | PiperOrigin-RevId: 169723724
* Pass "profile_path" flag to protoc if necessary.Gravatar Googler2017-07-26
| | | | | | | | This change adds a way to set proto profile artifact to ProtoCompileActionBuilder so that it passes profile_path flag to protocol_compiler. RELNOTES: None. PiperOrigin-RevId: 163155532
* Close the ZipFileSystem and the underlying ZipFile appropriately after we ↵Gravatar lberki2017-07-26
| | | | | | | | | | | finished extracting the FDO profile. Also fix a truly embarrassing infinite recursion bug introduced by Yours Truly in unknown commit . This avoids a failure mode where, when two profiles at the same path are used in two builds close one after the other, the file handle would get erroneously re-used. RELNOTES: None. PiperOrigin-RevId: 163063976
* Ignore unknown file types in profile zip filesGravatar Googler2017-07-07
| | | | | | | Allows profiles for both GCC and LLVM builds to co-exist in the same zip file. RELNOTES: none PiperOrigin-RevId: 161196188
* Fix LIPO to ThinLTO mapping to work with AutoFDO.Gravatar Googler2017-06-22
| | | | | | | | LIPO to ThinLTO mapping was added in https://github.com/bazelbuild/bazel/commit/c61f86f56b86e442369725ad79299ccc5519b000. This fixes a bug to ignore lipo context when compiler is LLVM. RELNOTES:None PiperOrigin-RevId: 159776286
* Map LIPO to ThinLTO when LLVM compiler is used.Gravatar Googler2017-06-14
| | | | | | | | | | | | This change maps LIPO to ThinLTO when a LLVM compiler is used for building, with a warning. This change is necessary for the following reason. The compiler team is planning to flip the default compiler from GCC to LLVM and this change will migrate all LIPO users of GCC to LLVM with ThinLTO + FDO (LIPO equivalent) without any changes to build scripts. RELNOTES[NEW]: LIPO maps to ThinLTO for LLVM builds. PiperOrigin-RevId: 158875330
* Add support for zipped LLVM profile files.Gravatar Googler2017-06-14
| | | | | | | | | | | | | | | | | | | This change is a follow-up to a recent change which allowed LLVM raw profile files to be directly used with blaze. This change allows zipped LLVM raw profile files. This uses //tools/zip:zipper to extract the zipped file contents. This also adds a new option to //tools/zip:zipper, 'j', to junk directories while unzipping. Tested: blaze test //devtools/blaze/integration:fdo_test blaze test //third_party/ijar/test:zip_test RELNOTES[NEW]: Zipped LLVM profiles are now supported. PiperOrigin-RevId: 158849516
* Make the error message when a file is not found in the profile zip more ↵Gravatar lberki2017-06-08
| | | | | | | indicative of the probable cause of the error. RELNOTES: None. PiperOrigin-RevId: 158286091
* Convert LLVM raw profiles to indexed format if necessary.Gravatar Googler2017-04-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Here is what is done today: bazel build -c opt --fdo_optimize=<path_to_profdata_file> //target The .profdata file is the LLVM profiles in indexed format and bazel creates a symlink to it from bazel-fdo/_fdo/... and compiles the target. However, the instrumented binary generates a .profraw file and hence the conversion to .profdata must be done manually using the llvm-profdata binary which is shipped along with the crosstool as: $ llvm-profdata -merge -o <path_to_profdata_file> <path_profraw_file> We are trying to avoid this intermediate step in this change by baking this into bazel. This implementation does the following: * In CppConfiguration.java, adds new tool llvm-profdata. * In CcToolchain.java, in function create, if LLVM instrumented FDO is desired, the profile format is checked and the profile conversion takes place. * FdoSupport.java checks for LLVM instrumented FDO is bypassed. RELNOTES[NEW]: Raw LLVM profiles are now supported. PiperOrigin-RevId: 154569896
* Add documentation for the (otherwise very confusing) :lipo_context attribute.Gravatar lberki2017-04-24
| | | | | RELNOTES: None. PiperOrigin-RevId: 153807467
* Don't create the LIPO context collector subgraph for instrumentation builds.Gravatar gregce2017-04-24
| | | | | | | | | The consumers of ":lipo_context_collector" only do anything with it in optimization builds. Also remove an outdated comment in FdoSupport. PiperOrigin-RevId: 153748937
* Remove an unused argument from FdoSupport#getGcdaArtifactsForGcdaPath().Gravatar lberki2017-04-24
| | | | | RELNOTES: None. PiperOrigin-RevId: 153716003
* Refactor all ctor callsites of PathFragment to instead call a static ↵Gravatar nharmata2017-04-05
| | | | | | | | | | | | 'create' method. This paves the way for changing PathFragment to e.g. an abstract class with multiple subclasses. This way we can split out the windows-specific stuff into one of these concrete classes, making the code more readable and also saving memory (since the shallow heap size of the NonWindowsPathFragment subclass will hopefully be smaller than that of the current PathFragment). This also lets us pursue gc churn optimizations. We can now do interning in PathFragment#create and can also get rid of unnecessary intermediate PathFragment allocations. RELNOTES: None PiperOrigin-RevId: 152145768
* Fix a bug in parsing .afdo.imports files whereupon Blaze would crash if a ↵Gravatar Lukacs Berki2017-02-15
| | | | | | | | line in that file wasn't empty but also didn't contain a colon. -- PiperOrigin-RevId: 147589431 MOS_MIGRATED_REVID=147589431
* Stop retrieving FdoSupport statically from hard-coded attribute ↵Gravatar Rumou Duan2017-02-14
| | | | | | | | | | ":cc_toolchain" in RuleContext, instead take the provider from users and pass it around to where it is used. This gives J2ObjcAspect the ability to specify the C++ toolchain attribute under a different name to avoid attribute conflicts with attached rules that have already declared attribute ":cc_toolchain". -- PiperOrigin-RevId: 147358325 MOS_MIGRATED_REVID=147358325
* Do not store two profile artifacts in FdoSupportProvider.Gravatar Lukacs Berki2017-02-07
| | | | | | -- PiperOrigin-RevId: 146757663 MOS_MIGRATED_REVID=146757663
* Create FDO stub actions during the analysis of the cc_toolchain rule for the ↵Gravatar Lukacs Berki2017-02-06
| | | | | | | | | | optimized configuration instead of for every single cc_library rule that compiles optimized code. This makes Blaze create many less FDO stub actions and almost always makes them non-shared. -- PiperOrigin-RevId: 146665855 MOS_MIGRATED_REVID=146665855
* Pass AutoFDO profiles to LTO backend.Gravatar Googler2017-01-18
| | | | | | -- PiperOrigin-RevId: 144841772 MOS_MIGRATED_REVID=144841772
* Simplify Crosstool Build Variables contextGravatar Marcel Hlopko2016-11-16
| | | | | | | | | | | | | | This cl merges two classes used to hold build variables context into one. Those classes are (previously top-level) jcgd.build.lib.rules.cpp.Variables, and its inner class View. Both represent a collection of build variables and imo it makes sense to merge them to make the code simpler. Also, I cleaned up the build variables api to use primitive strings or instances of VariableValueBuilders, and I've hidden subclasses of VariableValues. Last but not least, I refactored the code to use immutable collections exclusively. That revealed that 'module_files' variable is sometimes registered twice. I want to clean this eventually ([]). -- MOS_MIGRATED_REVID=139329823
* Add an "is main repo" field to RootsGravatar Kristina Chodorow2016-09-09
| | | | | | | This is part of prepping for #1262. -- MOS_MIGRATED_REVID=132553178
* Allow Skyframe graph lookups and value retrievals to throw InterruptedException.Gravatar Janak Ramakrishnan2016-08-16
| | | | | | | The only place we now don't handle InterruptedException is in the action graph created after analysis, since I'm not sure that will be around for that much longer. -- MOS_MIGRATED_REVID=130327770
* Replace the occurrences of Constants.PRODUCT_NAME for a call toGravatar Luis Fernando Pino Duque2016-05-23
| | | | | | | | | BlazeRuntime#getProductName() or a reference to TestConstants.PRODUCT_NAME for tests. This CL prepares the codebase in order to delete the constant. -- MOS_MIGRATED_REVID=122993568
* cpp fdo: Use correct PRODUCT_NAME for path when extracting a profile.Gravatar Svilen Kanev2016-04-27
| | | | | | | | | | | Profiles with a root 'blaze-fdo' didn't get correctly symlinked to execRoot/_fdo in bazel. TESTED=./compile.sh all; +manual FDO builds. -- Change-Id: I5cd69970523db4de15d5b6ddf7af4a072bbca0f5 Reviewed-on: https://bazel-review.googlesource.com/#/c/3490/ MOS_MIGRATED_REVID=120811529
* Move FDO support to the analysis phase by wrapping FdoSupport in its own ↵Gravatar Lukacs Berki2016-04-07
| | | | | | | | | | | SkyFunction. This removes one of the two reasons for the existence of BuildConfiguration#prepareToBuild() which makes implementing dynamic configurations impossible and also makes FDO support halfway sane; now FDO is exactly as ugly as remote repositories, that is to say, reasonably okay. Ideally, we'd implement the zip extraction as an Action and make it a TreeArtifact, but support for TreeArtifacts is not mature yet enough, so it's not possible at the moment. -- MOS_MIGRATED_REVID=119150223
* Pass the source path -> Artifact mapping into FdoSupport from a provider ↵Gravatar Lukacs Berki2016-02-28
| | | | | | | | | instead of special-casing it. This removes the need to deserialize artifacts in FdoSupport, which in turn removes the need to support artifact deserialization at all, which makes our lives simpler and Thoreauvian programming is good. -- MOS_MIGRATED_REVID=115660698
* Remove the genfilesPath parameter from FdoSupport.prepareToBuild.Gravatar Ulf Adams2016-02-10
| | | | | | | | | | | | | | | | | This makes the fdo support independent of the configuration, and therefore safe to cache. The genfilesPath was only used in AutoFDO builds, which now use the full exec path to look up profiling data. The profile already refers to imported files through their full exec paths, so this approach is more consistent. Furthermore, if we ever have a source file with the same root-relative path as a generated file, these would conflict in the FdoSupport map, potentially leading to errors in the build. This may not be possible right now since such files would conflict in the label namespace and such conflicts are always resolved towards the generated file. -- MOS_MIGRATED_REVID=114204994
* Use Bazel Preconditions variant which avoids varargs array creationGravatar Mark Schaller2015-12-10
| | | | | | | Reduces garbage. -- MOS_MIGRATED_REVID=109914243
* Rationalize copyright headersGravatar Damien Martin-Guillerez2015-09-25
| | | | | | | | | | | The headers were modified with `find . -type f -exec 'sed' '-Ei' 's|Copyright 201([45]) Google|Copyright 201\1 The Bazel Authors|' '{}' ';'` And manual edit for not Google owned copyright. Because of the nature of ijar, I did not modified the header of file owned by Alan Donovan. The list of authors were extracted from the git log. It is missing older Google contributors that can be added on-demand. -- MOS_MIGRATED_REVID=103938715
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-23 03:37:27 +0000