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

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

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

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

[X86] Make all the NOREX CodeGenOnly instructions into postRA pseudos like 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

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