Summary: Constant fold switch inst when looking for trivial conditions to unswitch on.

Reviewers: sanjoy, chenli, hfinkel, efriedma

Subscribers: llvm-commits, mzolotukhin

Differential Revision: https://reviews.llvm.org/D29037

llvm-svn: 293250

the main pipeline.

This is a very straight forward port. Nothing weird or surprising.

This brings the number of missing passes from the new PM's pipeline down
to three.

llvm-svn: 293249

This is to fix the win7 bot that does not seem to be very
good at infering the type when it gets used in an initiliazer list.

llvm-svn: 293248

Reviewers: compnerd, rengolin

Reviewed By: rengolin

Subscribers: aemerson, llvm-commits, mgorny

Differential Revision: https://reviews.llvm.org/D28985

llvm-svn: 293247

This is an attempt to fix the win7 bot that does not seem to be very
good at infering the type when it gets used in an initiliazer list.

llvm-svn: 293246

This reverts commit r293238.
Even with that the win7 bot is still failing:
http://lab.llvm.org:8011/builders/lld-x86_64-win7/builds/3862

llvm-svn: 293245

Summary:
There are many NVVM intrinsics that we can't entirely get rid of, but
that nonetheless often correspond to target-generic LLVM intrinsics.

For example, if flush denormals to zero (ftz) is enabled, we can convert
@llvm.nvvm.ceil.ftz.f to @llvm.ceil.f32.  On the other hand, if ftz is
disabled, we can't do this, because @llvm.ceil.f32 will be lowered to a
non-ftz PTX instruction.  In this case, we can, however, simplify the
non-ftz nvvm ceil intrinsic, @llvm.nvvm.ceil.f, to @llvm.ceil.f32.

These transformations are particularly useful because they let us
constant fold instructions that appear in libdevice, the bitcode library
that ships with CUDA and essentially functions as its libm.

Reviewers: tra

Subscribers: hfinkel, majnemer, llvm-commits

Differential Revision: https://reviews.llvm.org/D28794

llvm-svn: 293244

Summary:
CannotBeOrderedLessThanZero(powi(x, exp)) returns true if
CannotBeOrderedLessThanZero(x).  But powi(-0, exp) is negative if exp is
odd, so we actually want to return SignBitMustBeZero(x).

Except that also isn't right, because we want to return true if x is
NaN, even if x has a negative sign bit.

What we really need in order to fix this is a consistent approach in
this function to handling the sign bit of NaNs.  Without this it's very
difficult to say what the correct behavior here is.

Reviewers: hfinkel, efriedma, sanjoy

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D28927

llvm-svn: 293243

Summary:
Some frontends emit a speculate-and-select idiom for sqrt, wherein they compute
sqrt(x), check if x is negative, and select NaN if it is:

  %cmp = fcmp olt double %a, -0.000000e+00
  %sqrt = call double @llvm.sqrt.f64(double %a)
  %ret = select i1 %cmp, double 0x7FF8000000000000, double %sqrt

This is technically UB as the LangRef is written today if %a is ever less than
-0.  But emitting code that's compliant with the current definition of sqrt
would require a branch, which would then prevent us from matching this idiom in
SelectionDAG (which we do today -- ISD::FSQRT has defined behavior on negative
inputs), because SelectionDAG looks at one BB at a time.

Nothing in LLVM takes advantage of this undefined behavior, as far as we can
tell, and the fact that llvm.sqrt has UB dates from its initial addition to the
LangRef.

Reviewers: arsenm, mehdi_amini, hfinkel

Subscribers: wdng, llvm-commits

Differential Revision: https://reviews.llvm.org/D28797

llvm-svn: 293242

With this the per-module pass pipeline is *extremely* close to the
legacy PM. The missing pieces are:
- PruneEH (or some equivalent)
- ArgumentPromotion
- LoopLoadElimination
- LoopUnswitch

I'm going to work through those in essentially that order but this seems
like a worthwhile incremental step toward the end state.

One difference in what I have here from the legacy PM is that I've
consolidated some of the per-function passes at the very end of the
pipeline into the main optimization function pipeline. The intervening
passes are *really* uninteresting and so this seems very likely to have
any effect other than minor improvement to locality.

Note that there are still some failures in the test suite, but the
compiler doesn't crash or assert.

Differential Revision: https://reviews.llvm.org/D29114

llvm-svn: 293241

[libFuzzer] simplify the value profiling callback further: don't use (idx MOD prime) on the hot path where it is useless anyway

llvm-svn: 293239

This is an attempt to fix the win7 bot that does not seem to be very
good at infering the type.

llvm-svn: 293238

llvm-svn: 293237

llvm-svn: 293236

llvm-svn: 293235

llvm-svn: 293234

Now, GlobalISel will be built by default. To turn that off, one has to
use -DLLVM_BUILD_GLOBAL_ISEL=OFF on the cmake command line.

<rdar://problem/30004433>

llvm-svn: 293232

The internal build issue has been resolved.

llvm-svn: 293231

Summary: This adds a fallback in case that the Intel compiler is failed to be detected correctly.

Reviewers: chapuni

Reviewed By: chapuni

Subscribers: llvm-commits, mgorny

Differential Revision: https://reviews.llvm.org/D27610

llvm-svn: 293230

llvm-svn: 293229

The translation scheme is mostly cribbed from FastISel, and it's not entirely
convincing semantically. But it does seem to work in the common cases and allow
variables to be printed so it can't be all wrong.

llvm-svn: 293228

This change reverts:

r293061: "[InstCombine] Canonicalize guards for NOT OR condition"
r293058: "[InstCombine] Canonicalize guards for AND condition"

They miscompile cases like:

```
declare void @llvm.experimental.guard(i1, ...)

define void @test_guard_not_or(i1 %A, i1 %B) {
  %C = or i1 %A, %B
  %D = xor i1 %C, true
  call void(i1, ...) @llvm.experimental.guard(i1 %D, i32 20, i32 30)[ "deopt"() ]
  ret void
}
```

because they do transfer the `i32 20, i32 30` parameters to newly
created guard instructions.

llvm-svn: 293227

This commit introduces a set of experimental intrinsics intended to prevent
optimizations that make assumptions about the rounding mode and floating point
exception behavior.  These intrinsics will later be extended to specify
flush-to-zero behavior.  More work is also required to model instruction
dependencies in machine code and to generate these instructions from clang
(when required by pragmas and/or command line options that are not currently
supported).

Differential Revision: https://reviews.llvm.org/D27028

llvm-svn: 293226

loop-unswitch in the main pipelines for the new PM.

All of these now work, and Clang built using this pipeline can build the
test suite and SPEC without hitting any asserts of ASan failures.

There are still some bugs hiding though -- 7 tests regress with the new
PM. I'm going to be investigating these, but it seems worthwhile to at
least get the pipelines in place so that others can play with them, and
they aren't completely broken.

Differential Revision: https://reviews.llvm.org/D29113

llvm-svn: 293225

R_X86_64_NONE can be emitted without a symbol associated (well,
in theory it should never be emitted in an ABI-compliant relocatable
object). So, if there's no symbol associated to a reloc, emit one
with an empty name, instead of crashing.

Ack'ed by Michael Spencer offline.

PR: 31768
llvm-svn: 293224

llvm-svn: 293223

llvm-svn: 293222

This should unbreak the Hexagon build bots.

llvm-svn: 293221

Summary:
-fno-function-sections was added as a default Sanitizer common cflag with
https://reviews.llvm.org/rL200683, the reasoning behind was that things would
break if linked with --gc-sections.

This appears to not be necessary anymore, as tests pass without, including
function-sections-are-bad.cc. There is a large benefit to having
function-sections when dealing with static libraries in terms of size and
dependencies that go away with --gc-sections.

Reviewers: kcc, eugenis

Reviewed By: eugenis

Subscribers: llvm-commits, mgorny

Differential Revision: https://reviews.llvm.org/D29132

llvm-svn: 293220

another declaration, ensure we actually serialize / deserialize that
declaration.

Before this patch, if another copy of the typedef were merged with the parsed
version, we would emit type information referring to the merged version and
consequently emit nothing about the parsed anonymous struct. This resulted in
us losing information, particularly the visible merged module set for the
parsed definition. Force that information to be emitted and to be loaded when
the typedef is used.

llvm-svn: 293219

llvm-svn: 293218

Implement a new clang-tidy check that suggests users replace dynamic exception specifications with noexcept exception specifications.

Patch by Don Hinton.

llvm-svn: 293217

Summary:
This does not actually fix the testcase in PR31761 (discussion is
ongoing on the testcase), but does fix a bug it exposes, where stores
were not properly clobbering loads.

We accomplish this by unifying the memory equivalence infratructure
back into the normal congruence infrastructure, and then properly
destroying congruence classes when memory state leaders disappear.

Reviewers: davide

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D29195

llvm-svn: 293216

We already have this fold when the lshr has one use, but it doesn't need that
restriction. We may be able to remove some code from foldShiftedShift().

Also, move the similar:
(X << C) >>u C --> X & (-1 >>u C)
...directly into visitLShr to help clean up foldShiftByConstOfShiftByConst().

That whole function seems questionable since it is called by commonShiftTransforms(),
but there's really not much in common if we're checking the shift opcodes for every
fold.

llvm-svn: 293215

I think the initial version of r293172 was trying:
  std::forward<Args...>(args)...
which doesn't compile.  This seems like the correct way:
  std::forward<Args>(args)...

llvm-svn: 293214

llvm-svn: 293213

llvm-svn: 293212

llvm-svn: 293210

IRGen: When loading the main module in the distributed ThinLTO backend, look for the module containing the summary.

Differential Revision: https://reviews.llvm.org/D29067

llvm-svn: 293209

llvm-svn: 293208