| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
Follow-up to D38226.
llvm-svn: 314190
|
|
|
|
|
|
| |
Follow-up to D38226.
llvm-svn: 314189
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change ensures that we don't link in the XRay runtime when building
shared libraries with clang. This doesn't prevent us from building
shared libraris tht have XRay instrumentation sleds, but it does prevent
us from linking in the static XRay runtime into a shared library.
The XRay runtime currently doesn't support dynamic registration of
instrumentation sleds in shared objects, which we'll start enabling in
the future. That work has to happen in the back-end and in the runtime.
Reviewers: rnk, pelikan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D38226
llvm-svn: 314188
|
|
|
|
|
|
|
|
| |
Adapt to LLVM TargetLibraryInfo changes in r314185.
See also https://reviews.llvm.org/D38106 and https://reviews.llvm.org/D37891
llvm-svn: 314187
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D38267
llvm-svn: 314186
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Usually the frontend communicates the size of wchar_t via metadata and
we can optimize wcslen (and possibly other calls in the future). In
cases without the wchar_size metadata we would previously try to guess
the correct size based on the target triple; however this is fragile to
keep up to date and may miss users manually changing the size via flags.
Better be safe and stop guessing and optimizing if the frontend didn't
communicate the size.
Differential Revision: https://reviews.llvm.org/D38106
llvm-svn: 314185
|
|
|
|
|
|
| |
Changing all types to be byte-aligned broke a small number of tests.
llvm-svn: 314183
|
|
|
|
|
|
| |
Thanks to Eli Friedman for the suggestion.
llvm-svn: 314182
|
|
|
|
|
|
|
| |
This patch alone is neutral in terms of code readability, but this
change makes a following patch easier to read.
llvm-svn: 314181
|
|
|
|
|
|
|
|
|
|
|
| |
spot as the original MBB
Discovered in avr-rust/rust#62
https://github.com/avr-rust/rust/issues/62
Patch by Gergo Erdi.
llvm-svn: 314180
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was an oversight in the original backend data layout.
The AVR architecture does not have the concept of unaligned loads - all
loads/stores from all addresses are aligned to one byte.
Discovered in avr-rust issue #64
https://github.com/avr-rust/rust/issues/64
Patch By Gergo Erdi.
llvm-svn: 314179
|
|
|
|
|
|
| |
Reverts r314177.
llvm-svn: 314178
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change ensures that we don't link in the XRay runtime when building
shared libraries with clang. This doesn't prevent us from building
shared libraris tht have XRay instrumentation sleds, but it does prevent
us from linking in the static XRay runtime into a shared library.
The XRay runtime currently doesn't support dynamic registration of
instrumentation sleds in shared objects, which we'll start enabling in
the future. That work has to happen in the back-end and in the runtime.
Reviewers: rnk, pelikan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D38226
llvm-svn: 314177
|
|
|
|
| |
llvm-svn: 314176
|
|
|
|
|
|
|
|
|
|
| |
llvm-cov's report mode does not print any output when -show-functions is
specified and no source files are specified. This can be surprising, so
the tool should at least print out an error message when this happens.
rdar://problem/34636859
llvm-svn: 314175
|
|
|
|
| |
llvm-svn: 314174
|
|
|
|
| |
llvm-svn: 314173
|
|
|
|
|
|
| |
Previously, it was missing if the expression after the assert started with a (.
llvm-svn: 314172
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is the follow-up patch to D37924.
This change refactors clang to use the the newly added section headers
in SpecialCaseList to specify which sanitizers blacklists entries
should apply to, like so:
[cfi-vcall]
fun:*bad_vcall*
[cfi-derived-cast|cfi-unrelated-cast]
fun:*bad_cast*
The SanitizerSpecialCaseList class has been added to allow querying by
SanitizerMask, and SanitizerBlacklist and its downstream users have been
updated to provide that information. Old blacklists not using sections
will continue to function identically since the blacklist entries will
be placed into a '[*]' section by default matching against all
sanitizers.
Reviewers: pcc, kcc, eugenis, vsk
Reviewed By: eugenis
Subscribers: dberris, cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D37925
llvm-svn: 314171
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Sanitizer blacklist entries currently apply to all sanitizers--there
is no way to specify that an entry should only apply to a specific
sanitizer. This is important for Control Flow Integrity since there are
several different CFI modes that can be enabled at once. For maximum
security, CFI blacklist entries should be scoped to only the specific
CFI mode(s) that entry applies to.
Adding section headers to SpecialCaseLists allows users to specify more
information about list entries, like sanitizer names or other metadata,
like so:
[section1]
fun:*fun1*
[section2|section3]
fun:*fun23*
The section headers are regular expressions. For backwards compatbility,
blacklist entries entered before a section header are put into the '[*]'
section so that blacklists without sections retain the same behavior.
SpecialCaseList has been modified to also accept a section name when
matching against the blacklist. It has also been modified so the
follow-up change to clang can define a derived class that allows
matching sections by SectionMask instead of by string.
Reviewers: pcc, kcc, eugenis, vsk
Reviewed By: eugenis, vsk
Subscribers: vitalybuka, llvm-commits
Differential Revision: https://reviews.llvm.org/D37924
llvm-svn: 314170
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It leads to some improvements, but also a regression for the simple
case, so it's not clearly a good idea.
test/CodeGen/ARM/vcvt.ll now has test coverage to show the difference.
Ultimately, the right solution is probably to custom-lower fp-to-int
conversions, to something like ARMISD::VCVT_F32_S32 plus a bitcast.
It's hard to do the right thing when the implicit bitcast isn't visible
to DAG transforms.
llvm-svn: 314169
|
|
|
|
|
|
|
|
|
| |
In r296921, we added the G_[UN]MERGE_VALUES node, but did not update the
documentation. Fixing that.
NFC.
llvm-svn: 314168
|
|
|
|
|
|
|
|
| |
This instruction has been removed in r306120.
NFC.
llvm-svn: 314167
|
|
|
|
|
|
|
|
|
| |
In r297100, G_EXTRACT changed from a multiple results instruction to a
single result one. Update the documentation accordingly.
NFC.
llvm-svn: 314166
|
|
|
|
|
|
|
|
| |
R12 is used for the SwiftError parameter. It is no longer a CSR as it
is used for transfer the SwiftError, and the caller must preserve it if
they need to.
llvm-svn: 314165
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Enable the -nocudalib flag for the OpenMP device offloading toolchain as well. Currently it can only be used for the CUDA toolchain.
Reviewers: Hahnfeld, ABataev, carlo.bertolli, caomhin, hfinkel, tra
Reviewed By: tra
Subscribers: hfinkel, cfe-commits
Differential Revision: https://reviews.llvm.org/D37913
llvm-svn: 314164
|
|
|
|
|
|
|
| |
This is what I meant to do in r314161; I didn't realize I'd messed up
because the generated assembly is currently identical.
llvm-svn: 314163
|
|
|
|
| |
llvm-svn: 314162
|
|
|
|
| |
llvm-svn: 314161
|
|
|
|
| |
llvm-svn: 314160
|
|
|
|
|
|
| |
Missed a line in r314158.
llvm-svn: 314159
|
|
|
|
|
|
| |
I'm not sure why yet, but there may be differences depending on the host?
llvm-svn: 314158
|
|
|
|
| |
llvm-svn: 314157
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
needed.
Summary: When composing the output file name, the path to the file is being dropped. The full path is required.
Reviewers: Hahnfeld, ABataev, caomhin, carlo.bertolli, hfinkel, tra
Reviewed By: tra
Subscribers: hfinkel, tra, cfe-commits
Differential Revision: https://reviews.llvm.org/D37912
llvm-svn: 314156
|
|
|
|
|
|
|
|
|
| |
in TestDataFormatterSkipSummary.py - I'm building this test
with the default c++ library.
Skip TestMTCSimple.py when running for i386.
llvm-svn: 314155
|
|
|
|
| |
llvm-svn: 314154
|
|
|
|
|
|
|
|
|
|
| |
foldICmpUsingKnownBits
All this optimization cares about is knowing how many low bits of LHS is known to be zero and whether that means that the result is 0 or greater than the RHS constant. It doesn't matter where the zeros in the low bits came from. So we don't need to specifically look for an AND. Instead we can use known bits.
Differential Revision: https://reviews.llvm.org/D38195
llvm-svn: 314153
|
|
|
|
|
|
|
|
|
|
|
|
| |
instead.
As far as I know SUBREG_TO_REG is stating that the upper bits are 0. But if we are just converting the GR32 with no checks, then we have no reason to say the upper bits are 0.
I don't really know how to test this today since I can't find anything that looks that closely at SUBREG_TO_REG. The test changes here seems to be some perturbance of register allocation.
Differential Revision: https://reviews.llvm.org/D38001
llvm-svn: 314152
|
|
|
|
|
|
| |
the NOREX version of TEST.
llvm-svn: 314151
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: If we only use the compiler front-end, do not throw an error about the cuda device library not being found. This allows the front-end to be run on systems where no Cuda installation is found.
Reviewers: Hahnfeld, ABataev, carlo.bertolli, caomhin, tra
Reviewed By: tra
Subscribers: hfinkel, tra, cfe-commits
Differential Revision: https://reviews.llvm.org/D37914
llvm-svn: 314150
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
defined
Summary:
Platforms that don't implement procmaps (primarily fuchsia and windows) still expose
the procmaps API when including sanitizer_procmaps.h, despite not implementing the functions
provided by that header. Ensure that the API is only exposed on platforms that implement it.
Reviewers: vitalybuka, alekseyshl, kubamracek
Subscribers: llvm-commits, krytarowski
Differential Revision: https://reviews.llvm.org/D38187
llvm-svn: 314149
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change refactors some of the code to allow for some code
deduplication in later diffs as well as just to make adding a new
section type more self contained to the class itself. The idea for this
was first mentioned by James in D 37915 and will be used in that change
as recommended.
This change follows changes for dynamic sections but precedes support
for dynamic relocations.
Differential Revision: https://reviews.llvm.org/D38008
llvm-svn: 314148
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 1st attempt at this:
https://reviews.llvm.org/rL314117
was reverted at:
https://reviews.llvm.org/rL314118
because of bot fails for clang tests that were checking optimized IR. That should be fixed with:
https://reviews.llvm.org/rL314144
...so try again.
Original commit message:
The transform to convert an extract-of-a-select-of-vectors was added at:
https://reviews.llvm.org/rL194013
And a question about the validity of this transform was raised in the review:
https://reviews.llvm.org/D1539:
...but not answered AFAICT>
Most of the motivating cases in that patch are now handled by other combines. These are the tests that were added with
the original commit, but they are not regressing even after we remove the transform in this patch.
The diffs we see after removing this transform cause us to avoid increasing the instruction count, so we don't want to do
those transforms as canonicalizations.
The motivation for not turning a vector-select-of-vectors into a scalar operation is shown in PR33301:
https://bugs.llvm.org/show_bug.cgi?id=33301
...in those cases, we'll get vector ops with this patch rather than the vector/scalar mix that we currently see.
Differential Revision: https://reviews.llvm.org/D38006
llvm-svn: 314147
|
|
|
|
|
|
|
| |
In case the value used in a branch condition is a load instruction, assume this
load to be invariant.
llvm-svn: 314146
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
information of the pointer used in atomic expr" after fixing PR31620.
This is to fix PR34347. EmitAtomicExpr now only uses alignment information from
Type, instead of Decl, so when the declaration of an atomic variable is marked
to have the alignment equal as its size, EmitAtomicExpr doesn't know about it and
will generate libcall instead of atomic op. The patch uses EmitPointerWithAlignment
to get the precise alignment information.
Differential Revision: https://reviews.llvm.org/D37310
llvm-svn: 314145
|
|
|
|
|
|
|
|
| |
Clang regression tests that depend on the optimizer can break
when there are changes to LLVM...as in:
https://reviews.llvm.org/rL314117
llvm-svn: 314144
|
|
|
|
|
|
| |
No functionality change intended.
llvm-svn: 314143
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
builtins.", rL314135.
Causing assertion failures on macos:
> Assertion failed: (Num < NumOperands && "Invalid child # of SDNode!"),
> function getOperand, file
> /Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/llvm/include/llvm/CodeGen/SelectionDAGNodes.h,
> line 835.
http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/42739/testReport/LLVM/CodeGen_NVPTX/surf_read_cuda_ll/
llvm-svn: 314142
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes analyzer's crash on the newly added test case
(see also https://bugs.llvm.org/show_bug.cgi?id=34374).
Pointers subtraction appears to be modeled incorrectly
in the following example:
char* p;
auto n = p - reinterpret_cast<char*>((unsigned long)1);
In this case the analyzer (built without this patch)
tries to create a symbolic value for the difference
treating reinterpret_cast<char*>((unsigned long)1)
as an integer, that is not correct.
Differential revision: https://reviews.llvm.org/D38214
Test plan: make check-all
llvm-svn: 314141
|
|
|
|
|
|
|
|
|
| |
x86-asm-syntax=intel (PR34617).
Fix for incorrect code generation when x86-asm-syntax=intel.
Differential Revision: https://reviews.llvm.org/D37945
llvm-svn: 314140
|