Revision tags: llvmorg-14-init |
|
#
4e601325 |
| 09-Jul-2021 |
Arthur Eubanks <aeubanks@google.com> |
[NFC][OpaquePtr] Use GlobalValue::getValueType() more
Instead of getType()->getElementType().
|
Revision tags: llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3 |
|
#
8ace1213 |
| 21-Jun-2021 |
Nick Desaulniers <ndesaulniers@google.com> |
[IR] convert warn-stack-size from module flag to fn attr
Otherwise, this causes issues when building with LTO for object files that use different values.
Link: https://github.com/ClangBuiltLinux/li
[IR] convert warn-stack-size from module flag to fn attr
Otherwise, this causes issues when building with LTO for object files that use different values.
Link: https://github.com/ClangBuiltLinux/linux/issues/1395
Reviewed By: dblaikie, MaskRay
Differential Revision: https://reviews.llvm.org/D104342
show more ...
|
Revision tags: llvmorg-12.0.1-rc2 |
|
#
fc018ebb |
| 10-Jun-2021 |
Nick Desaulniers <ndesaulniers@google.com> |
[IR] make -warn-frame-size into a module attr
-Wframe-larger-than= is an interesting warning; we can't know the frame size until PrologueEpilogueInsertion (PEI); very late in the compilation pipelin
[IR] make -warn-frame-size into a module attr
-Wframe-larger-than= is an interesting warning; we can't know the frame size until PrologueEpilogueInsertion (PEI); very late in the compilation pipeline.
-Wframe-larger-than= was propagated through CC1 as an -mllvm flag, then was a cl::opt in LLVM's PEI pass; this meant it was dropped during LTO and needed to be re-specified via -plugin-opt.
Instead, make it part of the IR proper as a module level attribute, similar to D103048. Introduce -fwarn-stack-size CC1 option.
Reviewed By: rsmith, qcolombet
Differential Revision: https://reviews.llvm.org/D103928
show more ...
|
#
3787ee45 |
| 08-Jun-2021 |
Nick Desaulniers <ndesaulniers@google.com> |
reland [IR] make -stack-alignment= into a module attr
Relands commit 433c8d950cb3a1fa0977355ce0367e8c763a3f13 with fixes for MIPS.
Similar to D102742, specifying the stack alignment via CodegenOpts
reland [IR] make -stack-alignment= into a module attr
Relands commit 433c8d950cb3a1fa0977355ce0367e8c763a3f13 with fixes for MIPS.
Similar to D102742, specifying the stack alignment via CodegenOpts means that this flag gets dropped during LTO, unless the command line is re-specified as a plugin opt. Instead, encode this information as a module level attribute so that we don't have to expose this llvm internal flag when linking the Linux kernel with LTO.
Looks like external dependencies might need a fix: * https://github.com/llvm-hs/llvm-hs/issues/345 * https://github.com/halide/Halide/issues/6079
Link: https://github.com/ClangBuiltLinux/linux/issues/1377
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D103048
show more ...
|
#
a596b54d |
| 08-Jun-2021 |
Nick Desaulniers <ndesaulniers@google.com> |
Revert "[IR] make -stack-alignment= into a module attr"
This reverts commit 433c8d950cb3a1fa0977355ce0367e8c763a3f13.
Breaks the MIPS build.
|
#
433c8d95 |
| 08-Jun-2021 |
Nick Desaulniers <ndesaulniers@google.com> |
[IR] make -stack-alignment= into a module attr
Similar to D102742, specifying the stack alignment via CodegenOpts means that this flag gets dropped during LTO, unless the command line is re-specifie
[IR] make -stack-alignment= into a module attr
Similar to D102742, specifying the stack alignment via CodegenOpts means that this flag gets dropped during LTO, unless the command line is re-specified as a plugin opt. Instead, encode this information as a module level attribute so that we don't have to expose this llvm internal flag when linking the Linux kernel with LTO.
Looks like external dependencies might need a fix: * https://github.com/llvm-hs/llvm-hs/issues/345 * https://github.com/halide/Halide/issues/6079
Link: https://github.com/ClangBuiltLinux/linux/issues/1377
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D103048
show more ...
|
#
8d257627 |
| 27-May-2021 |
Hasyimi Bahrudin <hasyimi@ridebeam.com> |
Fix non-global-value-max-name-size not considered by LLParser
`non-global-value-max-name-size` is used by `Value` to cap the length of local value name. However, this flag is not considered by `LLPa
Fix non-global-value-max-name-size not considered by LLParser
`non-global-value-max-name-size` is used by `Value` to cap the length of local value name. However, this flag is not considered by `LLParser`, which leads to unexpected `use of undefined value error`. The fix is to move the responsibility of capping the length to `ValueSymbolTable`.
The test is the one provided by [[ https://bugs.llvm.org/show_bug.cgi?id=45899 | Mikael in the bug report ]].
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D102707
show more ...
|
Revision tags: llvmorg-12.0.1-rc1 |
|
#
033138ea |
| 21-May-2021 |
Nick Desaulniers <ndesaulniers@google.com> |
[IR] make stack-protector-guard-* flags into module attrs
D88631 added initial support for:
- -mstack-protector-guard= - -mstack-protector-guard-reg= - -mstack-protector-guard-offset=
flags, and D
[IR] make stack-protector-guard-* flags into module attrs
D88631 added initial support for:
- -mstack-protector-guard= - -mstack-protector-guard-reg= - -mstack-protector-guard-offset=
flags, and D100919 extended these to AArch64. Unfortunately, these flags aren't retained for LTO. Make them module attributes rather than TargetOptions.
Link: https://github.com/ClangBuiltLinux/linux/issues/1378
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D102742
show more ...
|
#
2786e673 |
| 23-Apr-2021 |
Fangrui Song <i@maskray.me> |
[IR][sanitizer] Add module flag "frame-pointer" and set it for cc1 -mframe-pointer={non-leaf,all}
The Linux kernel objtool diagnostic `call without frame pointer save/setup` arise in multiple instru
[IR][sanitizer] Add module flag "frame-pointer" and set it for cc1 -mframe-pointer={non-leaf,all}
The Linux kernel objtool diagnostic `call without frame pointer save/setup` arise in multiple instrumentation passes (asan/tsan/gcov). With the mechanism introduced in D100251, it's trivial to respect the command line -m[no-]omit-leaf-frame-pointer/-f[no-]omit-frame-pointer, so let's do it.
Fix: https://github.com/ClangBuiltLinux/linux/issues/1236 (tsan) Fix: https://github.com/ClangBuiltLinux/linux/issues/1238 (asan)
Also document the function attribute "frame-pointer" which is long overdue.
Differential Revision: https://reviews.llvm.org/D101016
show more ...
|
#
775a9483 |
| 21-Apr-2021 |
Fangrui Song <i@maskray.me> |
[IR][sanitizer] Set nounwind on module ctor/dtor, additionally set uwtable if -fasynchronous-unwind-tables
On ELF targets, if a function has uwtable or personality, or does not have nounwind (`needs
[IR][sanitizer] Set nounwind on module ctor/dtor, additionally set uwtable if -fasynchronous-unwind-tables
On ELF targets, if a function has uwtable or personality, or does not have nounwind (`needsUnwindTableEntry`), it marks that `.eh_frame` is needed in the module.
Then, a function gets `.eh_frame` if `needsUnwindTableEntry` or `-g[123]` is specified. (i.e. If -g[123], every function gets `.eh_frame`. This behavior is strange but that is the status quo on GCC and Clang.)
Let's take asan as an example. Other sanitizers are similar. `asan.module_[cd]tor` has no attribute. `needsUnwindTableEntry` returns true, so every function gets `.eh_frame` if `-g[123]` is specified. This is the root cause that `-fno-exceptions -fno-asynchronous-unwind-tables -g` produces .debug_frame while `-fno-exceptions -fno-asynchronous-unwind-tables -g -fsanitize=address` produces .eh_frame.
This patch
* sets the nounwind attribute on sanitizer module ctor/dtor. * let Clang emit a module flag metadata "uwtable" for -fasynchronous-unwind-tables. If "uwtable" is set, sanitizer module ctor/dtor additionally get the uwtable attribute.
The "uwtable" mechanism is generic: synthesized functions not cloned/specialized from existing ones should consider `Function::createWithDefaultAttr` instead of `Function::create` if they want to get some default attributes which have more of module semantics.
Other candidates: "frame-pointer" (https://github.com/ClangBuiltLinux/linux/issues/955 https://github.com/ClangBuiltLinux/linux/issues/1238), dso_local, etc.
Differential Revision: https://reviews.llvm.org/D100251
show more ...
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4 |
|
#
20ad206b |
| 25-Mar-2021 |
Mircea Trofin <mtrofin@google.com> |
[NFC] Module::getInstructionCount() is const
|
#
04790d9c |
| 19-Mar-2021 |
Jeroen Dobbelaere <jeroen.dobbelaere@synopsys.com> |
Support intrinsic overloading on unnamed types
This patch adds support for intrinsic overloading on unnamed types.
This fixes PR38117 and PR48340 and will also be needed for the Full Restrict Patch
Support intrinsic overloading on unnamed types
This patch adds support for intrinsic overloading on unnamed types.
This fixes PR38117 and PR48340 and will also be needed for the Full Restrict Patches (D68484).
The main problem is that the intrinsic overloading name mangling is using 's_s' for unnamed types. This can result in identical intrinsic mangled names for different function prototypes.
This patch changes this by adding a '.XXXXX' to the intrinsic mangled name when at least one of the types is based on an unnamed type, ensuring that we get a unique name.
Implementation details: - The mapping is created on demand and kept in Module. - It also checks for existing clashes and recycles potentially existing prototypes and declarations. - Because of extra data in Module, Intrinsic::getName needs an extra Module* argument and, for speed, an optional FunctionType* argument. - I still kept the original two-argument 'Intrinsic::getName' around which keeps the original behavior (providing the base name). -- Main reason is that I did not want to change the LLVMIntrinsicGetName version, as I don't know how acceptable such a change is -- The current situation already has a limitation. So that should not get worse with this patch. - Intrinsic::getDeclaration and the verifier are now using the new version.
Other notes: - As far as I see, this should not suffer from stability issues. The count is only added for prototypes depending on at least one anonymous struct - The initial count starts from 0 for each intrinsic mangled name. - In case of name clashes, existing prototypes are remembered and reused when that makes sense.
Reviewed By: fhahn
Differential Revision: https://reviews.llvm.org/D91250
show more ...
|
Revision tags: llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2 |
|
#
ef312951 |
| 24-Feb-2021 |
Fangrui Song <i@maskray.me> |
collectUsedGlobalVariables: migrate SmallPtrSetImpl overload to SmallVecImpl overload after D97128
And delete the SmallPtrSetImpl overload.
While here, decrease inline element counts from 8 to 4. S
collectUsedGlobalVariables: migrate SmallPtrSetImpl overload to SmallVecImpl overload after D97128
And delete the SmallPtrSetImpl overload.
While here, decrease inline element counts from 8 to 4. See D97128 for the choice.
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D97257
show more ...
|
#
3adb89bb |
| 23-Feb-2021 |
Fangrui Song <i@maskray.me> |
[ThinLTO] Make cloneUsedGlobalVariables deterministic
Iterating on `SmallPtrSet<GlobalValue *, 8>` with more than 8 elements is not deterministic. Use a SmallVector instead because `Used` is guarant
[ThinLTO] Make cloneUsedGlobalVariables deterministic
Iterating on `SmallPtrSet<GlobalValue *, 8>` with more than 8 elements is not deterministic. Use a SmallVector instead because `Used` is guaranteed to contain unique elements.
While here, decrease inline element counts from 8 to 4. The number of `llvm.used`/`llvm.compiler.used` elements is usually 0 or 1. For full LTO/hybrid LTO, the number may be large, so we need to be careful.
According to tejohnson's analysis https://reviews.llvm.org/D97128#2582399 , 4 is good for a large project with WholeProgramDevirt, when available_externally vtables are placed in the llvm.compiler.used set.
Differential Revision: https://reviews.llvm.org/D97128
show more ...
|
#
aa842896 |
| 12-Feb-2021 |
Igor Kudrin <ikudrin@accesssoftek.com> |
[DebugInfo] Keep the DWARF64 flag in the module metadata
This allows the option to affect the LTO output. Module::Max helps to generate debug info for all modules in the same format.
Differential R
[DebugInfo] Keep the DWARF64 flag in the module metadata
This allows the option to affect the LTO output. Module::Max helps to generate debug info for all modules in the same format.
Differential Revision: https://reviews.llvm.org/D96597
show more ...
|
Revision tags: llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1 |
|
#
d1fd7234 |
| 31-Dec-2020 |
Fangrui Song <i@maskray.me> |
Refactor how -fno-semantic-interposition sets dso_local on default visibility external linkage definitions
The idea is that the CC1 default for ELF should set dso_local on default visibility externa
Refactor how -fno-semantic-interposition sets dso_local on default visibility external linkage definitions
The idea is that the CC1 default for ELF should set dso_local on default visibility external linkage definitions in the default -mrelocation-model pic mode (-fpic/-fPIC) to match COFF/Mach-O and make output IR similar.
The refactoring is made available by 2820a2ca3a0e69c3f301845420e0067ffff2251b.
Currently only x86 supports local aliases. We move the decision to the driver. There are three CC1 states:
* -fsemantic-interposition: make some linkages interposable and make default visibility external linkage definitions dso_preemptable. * (default): selected if the target supports .Lfoo$local: make default visibility external linkage definitions dso_local * -fhalf-no-semantic-interposition: if neither option is set or the target does not support .Lfoo$local: like -fno-semantic-interposition but local aliases are not used. So references can be interposed if not optimized out.
Add -fhalf-no-semantic-interposition to a few tests using the half-based semantic interposition behavior.
show more ...
|
Revision tags: llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1 |
|
#
93dc1b5b |
| 17-Nov-2020 |
Wei Wang <apollo.mobility@gmail.com> |
[Remarks][2/2] Expand remarks hotness threshold option support in more tools
This is the #2 of 2 changes that make remarks hotness threshold option available in more tools. The changes also allow th
[Remarks][2/2] Expand remarks hotness threshold option support in more tools
This is the #2 of 2 changes that make remarks hotness threshold option available in more tools. The changes also allow the threshold to sync with hotness threshold from profile summary with special value 'auto'.
This change expands remarks hotness threshold option -fdiagnostics-hotness-threshold in clang and *-remarks-hotness-threshold in other tools to utilize hotness threshold from profile summary.
Remarks hotness filtering relies on several driver options. Table below lists how different options are correlated and affect final remarks outputs:
| profile | hotness | threshold | remarks printed | |---------|---------|-----------|-----------------| | No | No | No | All | | No | No | Yes | None | | No | Yes | No | All | | No | Yes | Yes | None | | Yes | No | No | All | | Yes | No | Yes | None | | Yes | Yes | No | All | | Yes | Yes | Yes | >=threshold |
In the presence of profile summary, it is often more desirable to directly use the hotness threshold from profile summary. The new argument value 'auto' indicates threshold will be synced with hotness threshold from profile summary during compilation. The "auto" threshold relies on the availability of profile summary. In case of missing such information, no remarks will be generated.
Differential Revision: https://reviews.llvm.org/D85808
show more ...
|
Revision tags: llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1 |
|
#
6c27c61d |
| 08-Apr-2020 |
Hiroshi Yamauchi <yamauchi@google.com> |
[PGO] Improve the working set size heuristics under the partial sample PGO.
Summary: The working set size heuristics (ProfileSummaryInfo::hasHugeWorkingSetSize) under the partial sample PGO may not
[PGO] Improve the working set size heuristics under the partial sample PGO.
Summary: The working set size heuristics (ProfileSummaryInfo::hasHugeWorkingSetSize) under the partial sample PGO may not be accurate because the profile is partial and the number of hot profile counters in the ProfileSummary may not reflect the actual working set size of the program being compiled.
To improve this, the (approximated) ratio of the the number of profile counters of the program being compiled to the number of profile counters in the partial sample profile is computed (which is called the partial profile ratio) and the working set size of the profile is scaled by this ratio to reflect the working set size of the program being compiled and used for the working set size heuristics.
The partial profile ratio is approximated based on the number of the basic blocks in the program and the NumCounts field in the ProfileSummary and computed through the thin LTO indexing. This means that there is the limitation that the scaled working set size is available to the thin LTO post link passes only.
Reviewers: davidxl
Subscribers: mgorny, eraman, hiraditya, steven_wu, dexonsmith, arphaman, dang, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D79831
show more ...
|
#
9d55e4ee |
| 25-May-2020 |
Fangrui Song <maskray@google.com> |
Make explicit -fno-semantic-interposition (in -fpic mode) infer dso_local
-fno-semantic-interposition is currently the CC1 default. (The opposite disables some interprocedural optimizations.) Howeve
Make explicit -fno-semantic-interposition (in -fpic mode) infer dso_local
-fno-semantic-interposition is currently the CC1 default. (The opposite disables some interprocedural optimizations.) However, it does not infer dso_local: on most targets accesses to ExternalLinkage functions/variables defined in the current module still need PLT/GOT.
This patch makes explicit -fno-semantic-interposition infer dso_local, so that PLT/GOT can be eliminated if targets implement local aliases for AsmPrinter::getSymbolPreferLocal (currently only x86).
Currently we check whether the module flag "SemanticInterposition" is 0. If yes, infer dso_local. In the future, we can infer dso_local unless "SemanticInterposition" is 1: frontends other than clang will also benefit from the optimization if they don't bother setting the flag. (There will be risks if they do want ELF interposition: they need to set "SemanticInterposition" to 1.)
show more ...
|
#
01909b4e |
| 13-May-2020 |
Hiroshi Yamauchi <yamauchi@google.com> |
[IR] Make Module::setProfileSummary to replace an existing ProfileSummary flag.
Summary: Module::setProfileSummary currently calls addModuelFlag. This prevents from updating the ProfileSummary metad
[IR] Make Module::setProfileSummary to replace an existing ProfileSummary flag.
Summary: Module::setProfileSummary currently calls addModuelFlag. This prevents from updating the ProfileSummary metadata in the module and results in a second ProfileSummary added instead of replacing an existing one. I don't think this is the expected behavior. It prevents updating the ProfileSummary and it does not make sense to have more than one. To address this, add Module::setModuleFlag and use it from setProfileSummary.
Reviewers: davidxl
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D79902
show more ...
|
Revision tags: llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1 |
|
#
73713f3e |
| 24-Jan-2020 |
Dominic Chen <d.c.ddcc@gmail.com> |
RNG: Take pass name as argument instead of pass pointer.
Summary: With the new pass manager, it is not possible to obtain a pointer to the pass.
Reviewers: jfb, rinon, yln
Subscribers: hiraditya,
RNG: Take pass name as argument instead of pass pointer.
Summary: With the new pass manager, it is not possible to obtain a pointer to the pass.
Reviewers: jfb, rinon, yln
Subscribers: hiraditya, dexonsmith, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D73390
show more ...
|
#
fd09f12f |
| 16-Jan-2020 |
serge-sans-paille <sguelton@redhat.com> |
Implement -fsemantic-interposition
First attempt at implementing -fsemantic-interposition.
Rely on GlobalValue::isInterposable that already captures most of the expected behavior.
Rely on a Module
Implement -fsemantic-interposition
First attempt at implementing -fsemantic-interposition.
Rely on GlobalValue::isInterposable that already captures most of the expected behavior.
Rely on a ModuleFlag to state whether we should respect SemanticInterposition or not. The default remains no.
So this should be a no-op if -fsemantic-interposition isn't used, and if it is, isInterposable being already used in most optimisation, they should honor it properly.
Note that it only impacts architecture compiled with -fPIC and no pie.
Differential Revision: https://reviews.llvm.org/D72829
show more ...
|
#
adcd0268 |
| 28-Jan-2020 |
Benjamin Kramer <benny.kra@googlemail.com> |
Make llvm::StringRef to std::string conversions explicit.
This is how it should've been and brings it more in line with std::string_view. There should be no functional change here.
This is mostly m
Make llvm::StringRef to std::string conversions explicit.
This is how it should've been and brings it more in line with std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
show more ...
|
#
46ed9331 |
| 18-Jan-2020 |
David Blaikie <dblaikie@gmail.com> |
[IR] Remove some unnecessary cleanup in Module's dtor, and use a unique_ptr to simplify some
Follow on from D72812, based on Mehdi Amini's feedback.
|
#
daab9227 |
| 15-Jan-2020 |
Brian Gesiak <modocache@gmail.com> |
[IR] Module's NamedMD table needn't be 'void *'
Summary: In July 21 2010 `llvm::NamedMDNode` was refactored such that it would no longer subclass `llvm::Value`: https://github.com/llvm/llvm-project/
[IR] Module's NamedMD table needn't be 'void *'
Summary: In July 21 2010 `llvm::NamedMDNode` was refactored such that it would no longer subclass `llvm::Value`: https://github.com/llvm/llvm-project/commit/2637cc1a38d7336ea30caf
As part of this change, a map type from metadata names to their named metadata, `llvm::MDSymbolTable`, was deleted. In its place, the type of member `llvm::Module::NamedMDSymTab` was changed, from `llvm::MDSymbolTable` to `void *`. The underlying memory allocations for this pointer were changed to `new StringMap<NamedMDNode *>()`.
However, as far as I can tell, there's no need for obscuring the underlying type being pointed to by the `void *`, and no need for static casts from `void *` to `StringMap`. In fact, I don't think there's a need for explicit calls to `new` and `delete` at all.
This commit changes `NamedMDSymTab` from a pointer to a reference, which automatically couples its lifetime with the lifetime of its owning `llvm::Module` instance, thus removing the explicit calls to `new` and `delete` in the `llvm::Module` constructor and destructor. It also changes the type from `void *` to a newly defined `NamedMDSymTabType`, and removes the static casts.
Test Plan: An ASAN-enabled build and run of `check-all` succeeds with this change (aside from some tests that always fail for me in ASAN for some reason, such as `check-clang` `SemaTemplate/stack-exhaustion.cpp`).
Reviewers: aprantl, dblaikie, chandlerc, pcc, echristo
Reviewed By: dblaikie
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D72812
show more ...
|