Remove unnecessary offset checks, CHECK-BASE checks and add some
extra -NOT checks and TODO comments.

llvm-svn: 353689

llvm-svn: 353688

Allow the use of ninja instead of make. This is useful on some
platforms where we'd like to be able to limit the number of link jobs
without slowing down the other steps of the release.

This patch adds a -use-ninja command line option, which sets the
generator to Ninja both for LLVM and the test-suite. It also deals with
some differences between make and ninja:
* DESTDIR handling - ninja doesn't like this to be listed after the
  target, but both make and ninja can handle it before the command
* Verbose mode - ninja uses -v, make uses VERBOSE=1
* Keep going mode - make has a -k mode, which builds as much as possible
  even when failures are encountered; for ninja we need to set a hard
  limit (we use 100 since most people won't look at 100 failures anyway)

I haven't tested with gmake.

llvm-svn: 353685

llvm-svn: 353683

Check that when SimplifyCFG is flattening a 'br', all their debug intrinsic instructions are removed, including any dbg.label referencing a label associated with the basic blocks being removed.

As the test case involves a CFG transformation, move it to the correct location.

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

llvm-svn: 353682

llvm-svn: 353681

Differential revision: https://reviews.llvm.org/D57945

llvm-svn: 353679

The whole design of generating LDMs/STMs is fragile and unreliable: it depends on
rescheduling here in the LoadStoreOptimizer that isn't register pressure aware
and regalloc that isn't aware of generating LDMs/STMs.
This patch adds a (hidden) option to control the total number of instructions that
can be re-ordered. I appreciate this looks only a tiny bit better than a hard-coded
constant, but at least it allows more easy experimentation with different values
for now. Ideally we calculate this reorder limit based on some heuristics, and take
register pressure into account. I might be looking into that next.

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

llvm-svn: 353678

instruction base class rather than the `CallSite` wrapper.

llvm-svn: 353676

Find dependent scripts of GenerateVersionFromVCS in current directory
rather than ../../cmake/modules.  I do not see any reason why the former
would not work and The latter is incorrect when GenerateVersionFromVCS
is used from install directory (i.e. in stand-alone builds).

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

llvm-svn: 353674

`CallBase` and simpler APIs therein.

llvm-svn: 353673

llvm-svn: 353672

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

llvm-svn: 353670

llvm-svn: 353667

llvm-svn: 353666

new one.

llvm-svn: 353665

llvm-svn: 353664

interface and implementation.

Port code with: `cast<CallBase>(CS.getInstruction())`.

llvm-svn: 353662

`CallBase`.

Users have been updated. You can see how to update any out-of-tree
usages: pass `cast<CallBase>(CS.getInstruction())`.

llvm-svn: 353661

`CallBase` class rather than `CallSite` wrappers.

I pushed this change down through most of the statepoint infrastructure,
completely removing the use of CallSite where I could reasonably do so.
I ended up making a couple of cut-points: generic call handling
(instcombine, TLI, SDAG). As soon as it hit truly generic handling with
users outside the immediate code, I simply transitioned into or out of
a `CallSite` to make this a reasonable sized chunk.

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

llvm-svn: 353660

llvm-svn: 353659

Patch by Mirko Bonadei <mbonadei@webrtc.org>!

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

llvm-svn: 353657

Minor refactor to simplify some incoming patches to improve broadcast loads.

llvm-svn: 353655

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

llvm-svn: 353652

Now that we have vector support for [US](ADD|SUB)O we no longer
need to scalarize when expanding [US](ADD|SUB)SAT.

This matches what the cost model already does.

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

llvm-svn: 353651

llvm-svn: 353648

Shows missing SimplifyDemandedBits support

llvm-svn: 353647

No change in default behaviour (AllowUndefs = false)

llvm-svn: 353646

Now that we have SimplifyDemandedBits support for funnel shifts (rL353539), we need to simplify funnel shifts back to bitshifts in cases where either argument has been folded to undef/zero.

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

llvm-svn: 353645

I've avoided 'modulo' masks as we'll SimplifyDemandedBits those in the future, and we just need to check that the shift variable is 'in range'

llvm-svn: 353644

256-bit horizontal math ops are an x86 monstrosity (and thankfully have
not been extended to 512-bit AFAIK).

The two 128-bit halves operate on separate halves of the inputs. So if we
don't demand anything in the upper half of the result, we can extract the
low halves of the inputs, do the math, and then insert that result into a
256-bit output.

All of the extract/insert is free (ymm<-->xmm), so we're left with a
narrower (cheaper) version of the original op.

In the affected tests based on:
https://bugs.llvm.org/show_bug.cgi?id=33758
https://bugs.llvm.org/show_bug.cgi?id=38971
...we see that the h-op narrowing can result in further narrowing of other
math via existing generic transforms.

I originally drafted this patch as an exact pattern match starting from
extract_vector_elt, but I thought we might see diffs starting from
extract_subvector too, so I changed it to a more general demanded elements
solution. There are no extra existing regression test improvements from
that switch though, so we could go back.

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

llvm-svn: 353641

As suggested on D58009 

llvm-svn: 353640

SimplifySetCC still has much room for improvement, but this should
fix the remaining problem examples from:
https://bugs.llvm.org/show_bug.cgi?id=40657

The initial fix for this problem was rL353615.

llvm-svn: 353639

llvm-svn: 353638

isInstructionTriviallyDead also performs the use_empty() check.

llvm-svn: 353637

This was introduced by me in r353613.

I tried to fix Big-endian bot and replaced
uintX_t -> ELFT::Xword. But ELFT::Xword is a packed<uint64_t>,
so it is always 8 bytes and that was obviously incorrect.

My intention was to use something like packed<uint> actually, which
size is target dependent.

Patch fixes this bug and adds a test case, since no bots seems reported this.

llvm-svn: 353636

We don't have any assembler predicates for vector ISAs so this isn't necessary. It just adds extra lines and identation.

llvm-svn: 353631

llvm-svn: 353630

If one of the shifted arguments is undef we should be folding to a regular shift.

llvm-svn: 353628

As discussed on D57389, this is a first step towards moving the SHLD/SHRD matching code to DAGCombiner using FSHL/FSHR instead.

There's a bit of work to do before I can do that, so this just folds to FSHL/FSHR in the existing code (handling the different SHRD/FSHR argument ordering), which fixes the issue we had with i16 shift amounts not being correctly masked.

llvm-svn: 353626