This is because if you set one of the variables to 0, if(NOT ...) is true, which isn't what you actually want. Should have thought that through better the first time.

llvm-svn: 250841

Summary:
This refactoring makes some of the code used to control including subdirectories parameterized so it can be re-used elsewhere.

Specifically I want to re-use this code in clang to be able to turn off specific tool subdirectories.

Reviewers: chapuni, filcab, bogner, Bigcheese

Subscribers: emaste, llvm-commits

Differential Revision: http://reviews.llvm.org/D13783

llvm-svn: 250835

  default: llvm_unreachable("This action is not supported yet!");

-- so I'm adding one to the third switch block, too.

This is a follow-up fix for http://reviews.llvm.org/D13862

llvm-svn: 250830

Don't use home brewed liveness tracking code for phys regs, since
this class does the job.

Reviewed by Ulrich Weigand.

llvm-svn: 250829

llvm-svn: 250828

Summary:
TargetLoweringBase::Expand is defined as "Try to expand this to other ops,
otherwise use a libcall." For ISD::UDIV and ISD::SDIV, the choice between
the two possibilities was defined in a rather convoluted way:

- if DIVREM is legal, expand to DIVREM
- if DIVREM has a custom lowering, expand to DIVREM
- if DIVREM libcall is defined and a remainder from the same division is
  computed elsewhere, expand to a DIVREM libcall
- else, expand to a DIV libcall

This had the undesirable effect that if both DIV and DIVREM are implemented
as libcalls, then ISD::UDIV and ISD::SDIV are expanded to the heavier DIVREM
libcall, even when the remainder isn't used.

The new code adds a new LegalizeAction, TargetLoweringBase::LibCall, so that
backends can directly control whether they prefer an expansion or a conversion
to a libcall. This makes the generic lowering code even more generic,
allowing its reuse in a wider range of target-specific configurations.

The useful effect is that ARM backend will now generate a call
to __aeabi_{i,u}div rather than __aeabi_{i,u}divmod in cases where
it doesn't need the remainder. There's no functional change outside
the ARM backend.

Reviewers: t.p.northover, rengolin

Subscribers: t.p.northover, llvm-commits, aemerson

Differential Revision: http://reviews.llvm.org/D13862

llvm-svn: 250826

Summary:
In addition to moving the code over, this patch amends the DIV,REM -> DIVREM
combining to run on all affected nodes at once: if the nodes are converted
to DIVREM one at a time, then the resulting DIVREM may get legalized by the
backend into something target-specific that we won't be able to recognize
and correlate with the remaining nodes.

The motivation is to "prepare terrain" for D13862: when we set DIV and REM
to be legalized to libcalls, instead of the DIVREM, we otherwise lose the
ability to combine them together. To prevent this, we need to take the
DIV,REM -> DIVREM combining out of the lowering stage.

Reviewers: RKSimon, eli.friedman, rengolin

Subscribers: john.brawn, rengolin, llvm-commits

Differential Revision: http://reviews.llvm.org/D13733

llvm-svn: 250825

Differential Revision: http://reviews.llvm.org/D13884

llvm-svn: 250819

The mask value type for maskload/maskstore GCC builtins is never a vector of
packed floats/doubles.

This patch fixes the following issues:
1. The mask argument for builtin_ia32_maskloadpd and builtin_ia32_maskstorepd
   should be of type llvm_v2i64_ty and not llvm_v2f64_ty.
2. The mask argument for builtin_ia32_maskloadpd256 and
   builtin_ia32_maskstorepd256 should be of type llvm_v4i64_ty and not
   llvm_v4f64_ty.
3. The mask argument for builtin_ia32_maskloadps and builtin_ia32_maskstoreps
   should be of type llvm_v4i32_ty and not llvm_v4f32_ty.
4. The mask argument for builtin_ia32_maskloadps256 and
   builtin_ia32_maskstoreps256 should be of type llvm_v8i32_ty and not
   llvm_v8f32_ty.

Differential Revision: http://reviews.llvm.org/D13776

llvm-svn: 250817

Summary: In r231241, TargetLibraryInfoWrapperPass was added to
`getAnalysisUsage` for `AddressSanitizer`, but the corresponding
`INITIALIZE_PASS_DEPENDENCY` was not added.

Reviewers: dvyukov, chandlerc, kcc

Subscribers: kcc, llvm-commits

Differential Revision: http://reviews.llvm.org/D13629

llvm-svn: 250813

llvm-svn: 250805

llvm-svn: 250797

symbol definition is found in the logical dylibs.

llvm-svn: 250796

This wasn't doing anything useful. They weren't explicitly used
anywhere, and the RegScavenger ignores reserved registers.

This for some reason caused a random scheduling change in the test.
Getting the check lines to pass is too frustrating, and there's probably
not too much value in checking the vector case's operands N times.

llvm-svn: 250794

They are now typeless, unlike other operations.

llvm-svn: 250793

llvm-svn: 250792

llvm-svn: 250791

llvm-svn: 250790

llvm-svn: 250788

llvm-svn: 250787

Since LiveVariables is uniqued (we just created it from a `DenseSet`),
`FindIndex(LiveVariables, LiveVariables[i])` is always `i`.

llvm-svn: 250786

 - Bring it up to the LLVM Coding Style
 - Sink it inside `CreateGCRelocates`, which is its only user

llvm-svn: 250785

`normalizeForInvokeSafepoint` in RewriteStatepointsForGC.cpp, as it is
written today, deals with `gc.relocate` and `gc.result` uses of a
statepoint equally well.  This change documents this fact and adds a
test case.

There is no functional change here -- only documentation of existing
functionality.

llvm-svn: 250784

llvm-svn: 250783

llvm-svn: 250781

llvm-svn: 250779

There are two things out of the ordinary in this commit.  First, I made
a loop obviously "infinite" in HexagonInstrInfo.cpp.  After checking if
an instruction was at the beginning of a basic block (in which case,
`break`), the loop decremented and checked the iterator for `nullptr` as
the loop condition.  This has never been possible (the prev pointers are
always been circular, so even with the weird ilist/iplist
implementation, this isn't been possible), so I removed the condition.

Second, in HexagonAsmPrinter.cpp there was another case of comparing a
`MachineBasicBlock::instr_iterator` against `MachineBasicBlock::end()`
(which returns `MachineBasicBlock::iterator`).  While not incorrect,
it's fragile.  I switched this to `::instr_end()`.

All that said, no functionality change intended here.

llvm-svn: 250778

llvm-svn: 250777

llvm-svn: 250776

llvm-svn: 250769

Mostly just converted to range-based for loops.  May have converted a
couple of extra loops as a drive-by (not sure).

llvm-svn: 250766

llvm-svn: 250765

llvm-svn: 250759

llvm-svn: 250758

llvm-svn: 250756

Currently, in MachineBlockPlacement pass the loop is rotated to let the best exit to be the last BB in the loop chain, to maximize the fall-through from the loop to outside. With profile data, we can determine the cost in terms of missed fall through opportunities when rotating a loop chain and select the best rotation. Basically, there are three kinds of cost to consider for each rotation:

1. The possibly missed fall through edge (if it exists) from BB out of the loop to the loop header.
2. The possibly missed fall through edges (if they exist) from the loop exits to BB out of the loop.
3. The missed fall through edge (if it exists) from the last BB to the first BB in the loop chain.

Therefore, the cost for a given rotation is the sum of costs listed above. We select the best rotation with the smallest cost. This is only for PGO mode when we have more precise edge frequencies.

Differential revision: http://reviews.llvm.org/D10717

llvm-svn: 250754

Thanks Dave!

llvm-svn: 250749

llvm-svn: 250748

As usual, this is a polymorphic hierarchy without polymorphic ownership,
so simply make the dtor protected non-virtual, protected default copy
ctor/assign, and make derived classes final. The derived classes will
pick up correct default public copy ops (and dtor) implicitly.

(wish I could add -Wdeprecated to the build, but last time I tried it
triggered on some system headers I still need to look into/figure out)

llvm-svn: 250747

Allow LLVM to optimize the sequence like the following:

  %inc = add nsw i32 %i, 1
  %cmp = icmp slt %n, %inc

into:

  %cmp = icmp sle i32 %n, %i

The case is not handled previously due to the complexity of compuation of %n.
Hence, LLVM cannot swap operands of icmp accordingly.

llvm-svn: 250746