| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This diff reorders the fields and removes excessive padding.
This fixes the following warning:
PTHLexer.cpp:629:7: warning: Excessive padding in 'class (anonymous namespace)::PTHStatData' (14 padding bytes, where 6 is optimal). Optimal fields order: Size, ModTime, UniqueID, HasData, IsDirectory, consider reordering the fields or adding explicit padding members.
Patch by: Alexander Shaposhnikov <shal1t712@gmail.com>
Differential Revision: https://reviews.llvm.org/D23826
llvm-svn: 279607
|
|
|
|
|
|
| |
This mirrors the option in libc++abi to build without libgcc.
llvm-svn: 279606
|
|
|
|
|
|
| |
is flagged by LSan at least among leak detectors.
llvm-svn: 279605
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We should not consider subregister definitions as reads for schedule
model purposes (they are just modeled as reads of the overal vreg for
liveness calculation purposes, the CPU instructions are not actually
reading).
Unfortunately I cannot submit a test for this as it requires a target
which uses ReadAdvance annotation in the scheduling model and has
subregister liveness enabled at the same time, which is only the case on
an out of tree target.
llvm-svn: 279604
|
|
|
|
|
|
| |
when compiling with optimization when PS4 is the target.
llvm-svn: 279603
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Re-apply this patch, hopefully I will get away without any warnings
in the constructor now.
This patch removes the MachineFunctionAnalysis. Instead we keep a
map from IR Function to MachineFunction in the MachineModuleInfo.
This allows the insertion of ModulePasses into the codegen pipeline
without breaking it because the MachineFunctionAnalysis gets dropped
before a module pass.
Peak memory should stay unchanged without a ModulePass in the codegen
pipeline: Previously the MachineFunction was freed at the end of a codegen
function pipeline because the MachineFunctionAnalysis was dropped; With
this patch the MachineFunction is freed after the AsmPrinter has
finished.
Differential Revision: http://reviews.llvm.org/D23736
llvm-svn: 279602
|
|
|
|
| |
llvm-svn: 279601
|
|
|
|
|
|
|
|
|
| |
Specifying isSSA is an extra line at best and results in invalid MI at
worst. Compute the value instead.
Differential Revision: http://reviews.llvm.org/D22722
llvm-svn: 279600
|
|
|
|
|
|
|
|
| |
sufficient in some cases; increase to 64KB, which should be enough for anyone :)
Patch by github.com/bryant!
llvm-svn: 279599
|
|
|
|
|
|
|
|
|
|
|
| |
Change this pass constructor to just accept a const TargetMachine * and
use INITIALIZE_TM_PASS, that way we can get rid of the dummy
constructor. The pass will still fail when calling the default
constructor leading to TM == nullptr, this is no different than before
but is more in line what other codegen passes are doing and avoids the
dummy constructor.
llvm-svn: 279598
|
|
|
|
|
|
|
| |
This reverts SVN r279584 which broke the buildbots. Will re-apply once the
issue has been root-caused and fixed.
llvm-svn: 279596
|
|
|
|
| |
llvm-svn: 279595
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is part of a serious of patches to evolve ADCE.cpp to support
removing of unnecessary control flow.
This patch adds the ability to compute control dependences using
the iterated dominance frontier. We extend the liveness propagation
to alternate between data and control dependences until convergences.
Modify the pass manager intergation to compute the post-dominator tree
needed for iterator dominance frontier.
We still force all terminators live for now until we add code to
handlinge removing control flow in a later patch.
No changes to effective behavior with this patch
Previous patches:
D23225 [ADCE] Modify data structures to support removing control flow
D23065 [ADCE] Refactor anticipating new functionality (NFC)
D23102 [ADCE] Refactoring for new functionality (NFC)
Reviewers: nadav, majnemer, mehdi_amini
Subscribers: twoh, freik, llvm-commits
Differential Revision: https://reviews.llvm.org/D23559
llvm-svn: 279594
|
|
|
|
| |
llvm-svn: 279590
|
|
|
|
| |
llvm-svn: 279589
|
|
|
|
| |
llvm-svn: 279588
|
|
|
|
| |
llvm-svn: 279587
|
|
|
|
|
|
| |
General cleanup before starting to work on the part I want to actually change.
llvm-svn: 279586
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In clang commit r268509 we started to invoke loop-unroll pass from the
driver even under -Os. However, we happen to not initialize optsize
thresholds properly, which si fixed with this change.
r268509 led to some big compile time regressions, because we started to
unroll some loops that we didn't unroll before. With this change I hope
to recover most of the regressions. We still are slightly slower than
before, because we do some checks here and there in loop-unrolling
before we bail out, but at least the slowdown is not that huge now.
Reviewers: hfinkel, chandlerc
Subscribers: mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D23388
llvm-svn: 279585
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We're compiling libc++ with -nodefaultlibs, so we should also pass this option
during the configuration checks to ensure those checks are consistent with the
actual build.
The primary motivation here is to ease cross-compilation against a non-standard
set of C++ libraries. Previously, the configuration checks would attempt to link
against the standard C++ libraries, which would cause link failures when
cross-compiling, even though the actual library link would go through correctly
(because of the use of -nodefaultlibs and explicitly specifying any needed
libraries). This is more correct even ignoring the motivation, however.
Patch by Shoaib Meenai!
llvm-svn: 279584
|
|
|
|
|
|
|
|
|
| |
since 2015 (n4387), though it's allowed by a library DR so new implementations
accept it in their C++11 modes...
This should unbreak the build with libstdc++ 4.9.
llvm-svn: 279583
|
|
|
|
|
|
| |
warnings.
llvm-svn: 279582
|
|
|
|
| |
llvm-svn: 279581
|
|
|
|
|
|
|
| |
dereferenced null pointer) in MachineModuleInfo::MachineModuleInfo that causes
-Werror builds (including several buildbots) to fail.
llvm-svn: 279580
|
|
|
|
| |
llvm-svn: 279579
|
|
|
|
| |
llvm-svn: 279578
|
|
|
|
|
|
|
|
|
|
| |
While these directives are mostly aliases for the existing integer
and float value directives, some of them like .dc.a have no direct
equivalents and are sometimes being used for convenience.
Differential Revision: https://reviews.llvm.org/D23810
llvm-svn: 279577
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add the ability to plug a cache on the LTO API.
I tried to write such that a linker implementation can
control the cache backend. This is intrusive and I'm
not totally happy with it, but I can't figure out a
better design right now.
Differential Revision: https://reviews.llvm.org/D23599
llvm-svn: 279576
|
|
|
|
|
|
|
| |
There will only be 3 lines of code in foldICmpShrConst() when the cleanup is done,
so it doesn't make much sense to have a separate function for a single fold.
llvm-svn: 279575
|
|
|
|
|
|
| |
This is a first step towards clarifying the exact MI semantics of stackmap's "live values".
llvm-svn: 279574
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I want to compute the SSA property of .mir files automatically in
upcoming patches. The problem with this is that some inputs will be
reported as static single assignment with some passes claiming not to
support SSA form. In reality though those passes do not support PHI
instructions => Track the presence of PHI instructions separate from the
SSA property.
Differential Revision: https://reviews.llvm.org/D22719
llvm-svn: 279573
|
|
|
|
|
|
| |
chunks instead of a lock-free linked list of tranfer batches. This change simplifies the code, makes the allocator more 'hardened', and will allow simpler code to release RAM to OS. This may also slowdown malloc stress tests due to lock contension, but I did not observe noticeable slowdown on various real multi-threaded benchmarks.
llvm-svn: 279572
|
|
|
|
| |
llvm-svn: 279571
|
|
|
|
|
|
| |
manual analysis of malloc performance)
llvm-svn: 279570
|
|
|
|
| |
llvm-svn: 279569
|
|
|
|
|
|
|
|
| |
AFAICT, these already worked in all cases for scalar types, and I enhanced
the code to work for vector types in:
https://reviews.llvm.org/rL279543
llvm-svn: 279568
|
|
|
|
|
|
|
| |
They really should have both types represented, but early variants were created
before MachineInstrs could have multiple types so they're rather ambiguous.
llvm-svn: 279567
|
|
|
|
|
|
|
| |
Next step is doing both legalizations at the same time! Marvel at GlobalISel's
cunning.
llvm-svn: 279566
|
|
|
|
| |
llvm-svn: 279565
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Re-apply this commit with the deletion of a MachineFunction delegated to
a separate pass to avoid use after free when doing this directly in
AsmPrinter.
This patch removes the MachineFunctionAnalysis. Instead we keep a
map from IR Function to MachineFunction in the MachineModuleInfo.
This allows the insertion of ModulePasses into the codegen pipeline
without breaking it because the MachineFunctionAnalysis gets dropped
before a module pass.
Peak memory should stay unchanged without a ModulePass in the codegen
pipeline: Previously the MachineFunction was freed at the end of a codegen
function pipeline because the MachineFunctionAnalysis was dropped; With
this patch the MachineFunction is freed after the AsmPrinter has
finished.
Differential Revision: http://reviews.llvm.org/D23736
llvm-svn: 279564
|
|
|
|
|
|
|
| |
No functional change intended, this should just be a code size
improvement.
llvm-svn: 279563
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test case included with r279125 exposed an existing signed integer
overflow. Since getTreeCost can return INT_MAX, we can't sum this cost together
with other costs, such as getReductionCost.
This patch removes the possibility of assigning a cost of INT_MAX. Since we
were previously using INT_MAX as an indicator for "should not vectorize", we
now explicitly check this condition with "isTreeTinyAndNotFullyVectorizable"
before computing a cost.
This patch adds a run-line to the test case used for r279125 that ensures we
don't vectorize. Previously, this line would vectorize the test case by chance
due to undefined behavior in the cost calculation.
Differential Revision: https://reviews.llvm.org/D23723
llvm-svn: 279562
|
|
|
|
| |
llvm-svn: 279561
|
|
|
|
|
|
|
| |
Reviewed By: lattner
Differential Revision: https://reviews.llvm.org/D23591
llvm-svn: 279560
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add a cmake check for sys/resource.h and replace the __has_include() check with its result, in order to make it possible to use rlimits when building with compilers not supporting __has_include() -- i.e. when bootstrapping.
// Please also re-apply dfcd52eb1d8e5d322404b40414cb7331c7380a8c (llvm-config.h fix)
Patch by: Michał Górny
Reviewers: rsmith, beanz
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D23744
llvm-svn: 279559
|
|
|
|
| |
llvm-svn: 279558
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to DiagnoseUninstantiableTemplate, teach hasVisibleDefinition to correctly
determine whether a function definition is visible, and mark both the function
and the template as visible when merging function template definitions to
provide hasVisibleDefinition with the relevant information.
The change to always pass the right declaration as the PatternDef to
DiagnoseUninstantiableTemplate also caused those checks to happen before other
diagnostics in InstantiateFunctionDefinition, giving worse diagnostics for the
same situations, so I sunk the relevant diagnostics into
DiagnoseUninstantiableTemplate. Those parts of this patch are based on changes
in reviews.llvm.org/D23492 by Vassil Vassilev.
This reinstates r279486, reverted in r279500, with a fix to
DiagnoseUninstantiableTemplate to only mark uninstantiable explicit
instantiation declarations as invalid if we actually diagnosed them. (When we
trigger an explicit instantiation of a class member from an explicit
instantiation declaration for the class, it's OK if there is no corresponding
definition and we certainly don't want to mark the member invalid in that
case.) This previously caused a build failure during bootstrap.
llvm-svn: 279557
|
|
|
|
|
|
|
| |
The output name changed, but it was passing locally
using the old output still present in the build dir.
llvm-svn: 279556
|
|
|
|
|
|
|
|
|
| |
/Brepro means we want reproducible builds, i.e. we _don't_ want the timestamp
that's needed to be compatible with the incremental linker.
https://reviews.llvm.org/D23805
llvm-svn: 279555
|
|
|
|
|
|
|
|
| |
Instructions like G_ICMP have multiple types that may need to be legalized (the
boolean output and nearly arbitrary inputs in this case). So the legalizer must
be capable of deciding what to do for each of them separately.
llvm-svn: 279554
|