llvm-svn: 330690

llvm-svn: 330689

llvm-svn: 330688

It doesn't make sense to non-deterministically choose between
`CopyPart(..)` and `InsertPart(..)` when it is known that
`InsertPart(..)` will fail.

This upstream's a change from JFS solver's fork of LibFuzzer.

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

llvm-svn: 330687

Follow-up for r330685.

llvm-svn: 330686

Add explicit dependency on ObjcopyTableGen 
and rerun the tests on Windows. 
I will double-check the build bots 
and revert this commit if necessary.

llvm-svn: 330685

llvm-svn: 330684

llvm-svn: 330683

This encoding is recognized by the CPU, but the behavior is undefined. This makes the disassembler handle it correctly so we don't print bswapl with a 16-bit register.

llvm-svn: 330682

The unmasked versions already didn't have this restrction. I don't think gcc or icc limit these to 64-bit mode so we shouldn't either.

llvm-svn: 330681

This code path can very clearly be called in a context where we have
baselined all the cloned blocks to a particular loop and are trying to
handle nested subloops. There is no harm in this, so just relax the
assert. I've added a test case that will make sure we actually exercise
this code path.

llvm-svn: 330680

llvm-svn: 330679

llvm-svn: 330678

llvm-svn: 330677

llvm-svn: 330676

No functional change intended.

llvm-svn: 330675

llvm-svn: 330674

The test is apparently needed e.g. for check-cfi on Windows where we get
  'C:/b/slave/sanitizer-windows/build/./bin/clang.exe': command not found
without it.  Try to fix the problem that was fixed by r330672 by also checking
for isabs() instead.

llvm-svn: 330673

lit's util.which() would check if the passed-in path existed directly,
and if so return it as-is.  This is never the case when running llvm's, clang's,
or lld's tests normally.  But when running `./llvm-lit path/to/clang/test`
with a cwd of llvm-build/bin, this if would detect that clang exists at path
'clang' and return 'clang' as the discovered clang binary -- and then lit would
use the " clang " -> "*** Do not use 'clang' in tests, use '%clang'. ***"
substitution to replace that with a broken test.  By removing this early
return, lit ends up with the usual absolute path and everything works even
in this uncommon case.

llvm-svn: 330672

llvm-svn: 330671

llvm-svn: 330670

(notionally Scalar.h is part of libLLVMScalarOpts, so it shouldn't be
included by InstCombine which doesn't/shouldn't need to depend on
ScalarOpts)

llvm-svn: 330669

I just tried to copy what was done for regular InstCombine. Hopefully I didn't miss anything.

llvm-svn: 330668

I was reminded today that this patch got reverted in r301885. I can no
longer reproduce the failure that caused the revert locally (...almost
one year later), and the patch applied pretty cleanly, so I guess we'll
see if the bots still get angry about it.

The original breakage was InstSimplify complaining (in "assertion
failed" form) about getting passed some crazy IR when running `ninja
check-sanitizer`. I'm unable to find traces of what, exactly, said crazy
IR was. I suppose we'll find out pretty soon if that's still the case.
:)

Original commit:

  Author: gbiv
  Date: Mon May  1 18:12:08 2017
  New Revision: 301880

  URL: http://llvm.org/viewvc/llvm-project?rev=301880&view=rev
  Log:
  [InstSimplify] Handle selects of GEPs with 0 offset

  In particular (since it wouldn't fit nicely in the summary):
  (select (icmp eq V 0) P (getelementptr P V)) -> (getelementptr P V)

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

llvm-svn: 330667

There're issues with IFUNC support on other platforms.

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

llvm-svn: 330666

There're issues with IFUNC support on other platforms.

DIfferential Revision: https://reviews.llvm.org/D45840

llvm-svn: 330665

llvm-svn: 330664

[AggressiveInstCombine] Add library initializer routine for AggressiveInstCombine library. Use it in bugpoint and llvm-opt-fuzzer to match regular InstCombine.

This should make aggressive instcombine usable with these tools.

llvm-svn: 330663

We have test coverage for these with resources-sse*/avx*

llvm-svn: 330662

Summary: Add DIBuilder bindings for (global) variable expressions, variable value expressions, and debug value intrinsic insertion.

Reviewers: harlanhaskins, deadalnix, whitequark

Reviewed By: whitequark

Subscribers: llvm-commits

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

llvm-svn: 330661

As we're becoming stricter w/ respect to not allowing vregs having LLTs
and regclasses assigned both mid-globalisel pipeline, the number of
extra copies grows, some of which separate G_UNMERGE's from their
corresponding G_MERGE's, becoming a performance concern.

It's worth mentioning that we're already looking through copies while
combining legalization artifacts for every kind of artifact but
G_UNMERGE.

Reviewed By: aditya_nandakumar

Reviewers: ab, t.p.northover, volkan, javed.absar

Subscribers: rovka, kristof.beyls, llvm-commits

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

llvm-svn: 330660

We have test coverage for these with resources-bmi2.s

llvm-svn: 330659

The 32-bit refers to their input/output type, but the instructions are only available in 64-bit mode.

llvm-svn: 330658

[X86] Move __builtin_ia32_movnti64 andd __builtin_ia32_rdrand64_step to BuiltinsX86_64.def to make them unavailable in 32-bit mode.

llvm-svn: 330657

This makes it return the right result in a couple of edge cases. The
wide versions always do the comparison on the underlying wchar_t type.

llvm-svn: 330656

There are 3 changes:
* Renamed genertor.pass.cpp to generator.pass.cpp
* Removed nothing_to_do.pass.cpp
* Mark GCC 4.9 as UNSUPPORTED for the test files that have negative
  narrowing conversion SFINAE test (see GCC PR63723).

llvm-svn: 330655

llvm-svn: 330654

If a loop with child loops becomes our new inner loop after
interchanging, we only need to update LoopInfo for the blocks defined in
the old outer loop. BBs in child loops will stay there.

Reviewers: efriedma, karthikthecool, mcrosier

Reviewed By: efriedma

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

llvm-svn: 330653

A small but substantial minority of libFuzzer-based fuzzers run code that
does not play well with fork in global constructors or LLVMFuzzerInitialize.
This patch allows these fuzzers to use afl_driver by allowing them to
opt-out of using AFL's deferred forkserver which deferres calling fork until
after this code.

Patch By: metzman

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

llvm-svn: 330652

Summary:
It seems there isn't much enthusiasm for `-wtest` D45685.

This is more conservative version, which i had in the very first
revision of D44883, but that 'erroneously' got removed because of the review.

**Based on some [irc] discussions, it must really be documented that
we want all the new diagnostics to have their own flags, to ease
rollouts, transitions, etc.**

Please do note that i'm only adding `-Wno-self-assign-overloaded`,
but not `-Wno-self-assign-field-overloaded`, because i'm honestly
not aware of any false-positives from the `-field` variant,
but i can just as easily add it if wanted.
https://reviews.llvm.org/D44883#1068561

Reviewers: dblaikie, aaron.ballman, thakis, rjmccall, rsmith

Reviewed By: dblaikie

Subscribers: Quuxplusone, chandlerc, cfe-commits

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

llvm-svn: 330651