| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 316732
|
| |
|
|
| |
llvm-svn: 316731
|
| |
|
|
|
|
|
|
| |
Previously, EhFrameSection pushes data to EhFrameHdr by calling addFde
function. By making EhFrameHdr pull data from EhFrameSection, we can
eliminate a member from EhFrameHdr.
llvm-svn: 316730
|
| |
|
|
| |
llvm-svn: 316729
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Using the in-tree clang should be the default test configuration as that
is the one compiler that we can be sure everyone has (better
reproducibility of test results). Also, it should hopefully reduce the
impact of pr35040.
This also reduces the number of settings which control the compiler
used. LLDB_TEST_C_COMPILER is used for C files and
LLDB_TEST_CXX_COMPILER for C++ files. Both of the settings default to
the in-tree clang.
Reviewers: zturner
Subscribers: mgorny, davide, lldb-commits
Differential Revision: https://reviews.llvm.org/D39215
llvm-svn: 316728
|
| |
|
|
| |
llvm-svn: 316727
|
| |
|
|
|
|
|
| |
In a rare situation, the function can fail (e.g. it fails if it cannot
open /dev/urandom.)
llvm-svn: 316726
|
| |
|
|
| |
llvm-svn: 316725
|
| |
|
|
|
|
| |
warnings; other minor fixes (NFC).
llvm-svn: 316724
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes an assertion failure when ivar is a struct containing incomplete
array. Also completes support for direct flexible array members.
rdar://problem/21054495
Reviewers: rjmccall, theraven
Reviewed By: rjmccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D38774
llvm-svn: 316723
|
| |
|
|
| |
llvm-svn: 316722
|
| |
|
|
|
|
| |
This reverts commit r316711. The domtree isn't getting updated correctly.
llvm-svn: 316721
|
| |
|
|
| |
llvm-svn: 316720
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D39218
llvm-svn: 316719
|
| |
|
|
|
|
| |
sse4 is valid for target attribute and functions as an alias of sse4.2.
llvm-svn: 316718
|
| |
|
|
|
|
|
|
|
|
|
| |
This ensures that each segment has a unique address.
Without this, consecutive zero sized symbols would
end up with the same address and the linker cannot
map symbols to unique data segments.
Differential Revision: https://reviews.llvm.org/D39107
llvm-svn: 316717
|
| |
|
|
| |
llvm-svn: 316716
|
| |
|
|
|
|
| |
static member function to expose the debug name
llvm-svn: 316715
|
| |
|
|
|
|
|
|
| |
Pointer traits require a full definition of a type to function
correctly, so the header must be included rather than only a forward
declaration.
llvm-svn: 316714
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
clang currently uses .init_array instead of .ctors on Linux if it detects gcc
4.7+. Make it so that it also uses .init_array if no gcc installation is found
at all – if there's no old gcc, there's nothing we need to be compatible with.
icecc for example runs clang in a very small chroot, so before this change
clang would use .ctors if run under icecc. And lld currently silently mislinks
inputs with .ctors sections, so before this clang + icecc + lld would produce
broken binaries. (But this seems like a good change independent of that lld
bug.)
https://reviews.llvm.org/D39317
llvm-svn: 316713
|
| |
|
|
|
|
|
|
| |
I think the only reason they are different is because we don't set tune_i686 for -march=i686 to match GCC. But GCC 4.9.0 seems to have changed this behavior and they do set it now. So I think they can aliases now.
Differential Revision: https://reviews.llvm.org/D39349
llvm-svn: 316712
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently we skip merging when extra moves may be added in the header of switch instead of the case block, if the case block is used as an incoming
block of a PHI. If all the incoming values of the PHIs are non-constants and the destination block is dominated by the switch block then extra moves are likely not added by ISel, so there is no need to skip merging in this case.
Reviewers: efriedma, junbuml, davidxl, hfinkel, qcolombet
Reviewed By: efriedma
Subscribers: dberlin, kuhar, mcrosier, llvm-commits
Differential Revision: https://reviews.llvm.org/D37343
llvm-svn: 316711
|
| |
|
|
|
|
|
| |
Because of the same reason as r316600, I don't think we need a guard
against empty relocations.
llvm-svn: 316710
|
| |
|
|
| |
llvm-svn: 316709
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As far as I can tell, this matches gcc: -mfloat-abi determines the
calling convention for all functions except those explicitly defined as
soft-float in the ARM RTABI.
This change only affects cases where the user specifies -mfloat-abi to
override the default calling convention derived from the target triple.
Fixes https://bugs.llvm.org//show_bug.cgi?id=34530.
Differential Revision: https://reviews.llvm.org/D38299
llvm-svn: 316708
|
| |
|
|
| |
llvm-svn: 316707
|
| |
|
|
|
|
|
|
| |
These headers have static variables in them, which would easily create
ODR violations if the header was included in another header, and the
constants were used by an inline function, for example.
llvm-svn: 316706
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Options.td file and pair them up with their negations.
It looks like at one time Options.td was in alphabetical order, but that looks to have long been broken. The result is that it all the no- x86 options got separated from their other friends for no good reason.
This patch puts them all together in one place with the no- paired with its none negated version.
I've kept all the SSE and AVX/AVX512 bits together since they represent a somewhat linear progression of features. The rest I just put in alphabetical order after.
Differential Revision: https://reviews.llvm.org/D39341
llvm-svn: 316705
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of only setting a non-zero debug location on the return
instruction in *_helper_block functions, set a proper location on all
instructions within these functions. Pick the start location of the
block literal expr for maximum clarity.
The debugger does not step into *_helper_block functions during normal
single-stepping because we mark their parameters as artificial. This is
what we want (the functions are implicitly generated and uninteresting
to most users). The stepping behavior is unchanged by this patch.
rdar://32907581
Differential Revision: https://reviews.llvm.org/D39310
llvm-svn: 316704
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: There are certain requirements for debug location of debug intrinsics, e.g. the scope of the DILocalVariable should be the same as the scope of its debug location. As a result, we should not add discriminator encoding for debug intrinsics.
Reviewers: dblaikie, aprantl
Reviewed By: aprantl
Subscribers: JDevlieghere, aprantl, bjope, sanjoy, llvm-commits
Differential Revision: https://reviews.llvm.org/D39343
llvm-svn: 316703
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
64-bit extensions.
If the extend type is 64-bits, emit a 32-bit -> 64-bit extend after the UDIVREM8_ZEXT_HREG/UDIVREM8_SEXT_HREG operation.
This gives a shorter encoding for the second extend in the sext case, and allows us to completely remove the second extend in the zext case.
This also adds known bit and num sign bits support for UDIVREM8_ZEXT_HREG/SDIVREM8_SEXT_HREG.
Differential Revision: https://reviews.llvm.org/D38275
llvm-svn: 316702
|
| |
|
|
| |
llvm-svn: 316701
|
| |
|
|
|
|
|
|
|
|
| |
instructions.
Fixes PR32238.
Differential Revision: https://reviews.llvm.org/D39077
llvm-svn: 316700
|
| |
|
|
|
|
| |
When going to explain this to someone else, I got tripped up by the complicated meaning of IsKnownNonEscapingObject in load-store promotion. Extract a helper routine and clarify naming/scopes to make this a bit more obvious.
llvm-svn: 316699
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
LSan is functional on PPC64 Linux now, let's enable all tests.
One test required ppc specific changes: use_registers.cc.
Reviewers: eugenis
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D39316
llvm-svn: 316698
|
| |
|
|
|
|
| |
PrintFatalError.
llvm-svn: 316697
|
| |
|
|
| |
llvm-svn: 316696
|
| |
|
|
| |
llvm-svn: 316695
|
| |
|
|
|
|
| |
legalizationCombiner
llvm-svn: 316694
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In GNU ld, this option is enabled by default, but can be set
to reduce some warnings.
For lld, ignore the flag (for now); in case linking still succeeds
everything should be fine, if not, it should be clear to the user
what part failed (possibly requiring adjusting the user project
to not rely on this feature), instead of straight out failing due to
an unknown flag.
Differential Revision: https://reviews.llvm.org/D39330
llvm-svn: 316693
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D39329
llvm-svn: 316692
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D39328
llvm-svn: 316691
|
| |
|
|
|
|
|
|
|
|
| |
Both GNU ld and MS link.exe support declaring ordinals this way.
A test will be added in lld.
Differential Revision: https://reviews.llvm.org/D39327
llvm-svn: 316690
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The exisiting code goes out of its way to put block parameters into an
alloca only at -O0, and then describes the funciton argument with a
dbg.declare, which is undocumented in the LLVM-CFE contract and does
not actually behave as intended after LLVM r642022.
This patch just generates the alloca unconditionally, the mem2reg pass
will eliminate it at -O1 and up anyway and points the dbg.declare to
the alloca as intended (which mem2reg will then correctly rewrite into
a dbg.value).
This reapplies r316684 with some dead code removed.
rdar://problem/35043980
Differential Revision: https://reviews.llvm.org/D39305
llvm-svn: 316689
|
| |
|
|
|
|
|
|
|
| |
The test was asserting that we can only find one frame in the minidump.
Now that we have the default unwind plan from the ABI plugin, we are
able to find 5 more frames using the frame pointer chaining. Correct the
expectation in the test.
llvm-svn: 316688
|
| |
|
|
|
|
|
| |
With this change it would be sufficient to look at CI console to see the
failure.
llvm-svn: 316687
|
| |
|
|
|
|
|
|
| |
parameters."
This reverts commit r316684 while investigating buildbot breakage.
llvm-svn: 316686
|
| |
|
|
|
|
|
|
| |
Instead of loading (a potential ton of) scalar constants, load those as a vector and then insert into it.
Differential Revision: https://reviews.llvm.org/D38756
llvm-svn: 316685
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The exisiting code goes out of its way to put block parameters into an
alloca only at -O0, and then describes the funciton argument with a
dbg.declare, which is undocumented in the LLVM-CFE contract and does
not actually behave as intended after LLVM r642022.
This patch just generates the alloca unconditionally, the mem2reg pass
will eliminate it at -O1 and up anyway and points the dbg.declare to
the alloca as intended (which mem2reg will then correctly rewrite into
a dbg.value).
rdar://problem/35043980
Differential Revision: https://reviews.llvm.org/D39305
llvm-svn: 316684
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
With new release to OS approach (see D38245) it's reasonable to enable
it by default. Setting allocator_release_to_os_interval_ms to 5000 seems
to be a reasonable default (might be tuned later, based on the
feedback).
Also delaying the first release to OS in each bucket for at least
allocator_release_to_os_interval_ms after the first allocation to
prevent just allocated memory to be madvised back to OS and let short
lived processes to avoid release to OS overhead altogether.
Reviewers: cryptoad
Subscribers: kubamracek, llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D39318
llvm-svn: 316683
|