Change Function::getIntrinsicID() to return an Intrinsic::ID. NFC.

Now that Intrinsic::ID is a typed enum, we can forward declare it and so return it from this method.

This updates all users which

Change Function::getIntrinsicID() to return an Intrinsic::ID. NFC.

Now that Intrinsic::ID is a typed enum, we can forward declare it and so return it from this method.

This updates all users which were either using an unsigned to store it, or had a now unnecessary cast.

llvm-svn: 237810

show more ...

MC: Clean up method names in MCContext.

The naming was a mish-mash of old and new style. Update to be consistent
with the new. NFC.

llvm-svn: 237594

Preserve the order of READ_REGISTER and WRITE_REGISTER

At the present time, we don't have a way to represent general dependency
relationships, so everything is represented using memory dependency. I

Preserve the order of READ_REGISTER and WRITE_REGISTER

At the present time, we don't have a way to represent general dependency
relationships, so everything is represented using memory dependency. In order
to preserve the data dependency of a READ_REGISTER on WRITE_REGISTER, we need
to model WRITE_REGISTER as writing (which we had been doing) and model
READ_REGISTER as reading (which we had not been doing). Fix this, and also the
way that the chain operands were generated at the SDAG level.

Patch by Nicholas Paul Johnson, thanks! Test case by me.

llvm-svn: 237584

show more ...

Revert r237579, as it broke windows buildbots

llvm-svn: 237583

[LLVM - ARM/AArch64] Add ACLE special register intrinsics

This patch implements LLVM support for the ACLE special register intrinsics in
section 10.1, __arm_{w,r}sr{,p,64}.

This patch is intended t

[LLVM - ARM/AArch64] Add ACLE special register intrinsics

This patch implements LLVM support for the ACLE special register intrinsics in
section 10.1, __arm_{w,r}sr{,p,64}.

This patch is intended to lower the read/write_register instrinsics, used to
implement the special register intrinsics in the clang patch for special
register intrinsics (see http://reviews.llvm.org/D9697), to ARM specific
instructions MRC,MCR,MSR etc. to allow reading an writing of coprocessor
registers in AArch32 and AArch64. This is done by inspecting the register
string passed to the intrinsic and then lowering to the appropriate
instruction.

Patch by Luke Cheeseman.

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

llvm-svn: 237579

show more ...

[SDAGBuilder] Make the AArch64 builder happier.

I intended this loop to only unwrap SplitVector actions, but it
was more broad than that, such as unwrapping WidenVector actions,
which makes operatio

[SDAGBuilder] Make the AArch64 builder happier.

I intended this loop to only unwrap SplitVector actions, but it
was more broad than that, such as unwrapping WidenVector actions,
which makes operations seem legal when they're not.

llvm-svn: 237457

show more ...

Add SDNodes for umin, umax, smin and smax.

This adds new SDNodes for signed/unsigned min/max. These nodes are built from
select/icmp pairs matched at SDAGBuilder stage.

This patch adds the nodes, a

Add SDNodes for umin, umax, smin and smax.

This adds new SDNodes for signed/unsigned min/max. These nodes are built from
select/icmp pairs matched at SDAGBuilder stage.

This patch adds the nodes, as well as legalization support and sets them to
be "expand" for all targets.

NFC for now; this will be tested when I switch AArch64 to using these new
nodes.

llvm-svn: 237423

show more ...

Revert r237046. See the testcase on the thread where r237046 was committed.

llvm-svn: 237317

propagate IR-level fast-math-flags to DAG nodes; 2nd try; NFC

This is a less ambitious version of:
http://reviews.llvm.org/rL236546

because that was reverted in:
http://reviews.llvm.org/rL236600

b

propagate IR-level fast-math-flags to DAG nodes; 2nd try; NFC

This is a less ambitious version of:
http://reviews.llvm.org/rL236546

because that was reverted in:
http://reviews.llvm.org/rL236600

because it caused memory corruption that wasn't related to FMF
but was actually due to making nodes with 2 operands derive from a
plain SDNode rather than a BinarySDNode.

This patch adds the minimum plumbing necessary to use IR-level
fast-math-flags (FMF) in the backend without actually using
them for anything yet. This is a follow-on to:
http://reviews.llvm.org/rL235997

...which split the existing nsw / nuw / exact flags and FMF
into their own struct.


llvm-svn: 237046

show more ...

Switch lowering: cluster adjacent fall-through cases even at -O0

It's cheap to do, and codegen is much faster if cases can be merged
into clusters.

llvm-svn: 236905

Fix coding standart based on post submit comments.

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

llvm-svn: 236849

Switch lowering: handle zero-weight branch probabilities

After r236617, branch probabilities are no longer guaranteed to be >= 1. This
patch makes the swich lowering code handle that correctly, with

Switch lowering: handle zero-weight branch probabilities

After r236617, branch probabilities are no longer guaranteed to be >= 1. This
patch makes the swich lowering code handle that correctly, without bumping the
branch weights by 1 which might cause overflow and skews the probabilities.

Covered by @zero_weight_tree in test/CodeGen/X86/switch.ll.

llvm-svn: 236739

show more ...

Allow 0-weight branches in BranchProbabilityInfo.

Summary:
When computing branch weights in BPI, we used to disallow branches with
weight 0. This is a minor nuisance, because a branch with weight 0

Allow 0-weight branches in BranchProbabilityInfo.

Summary:
When computing branch weights in BPI, we used to disallow branches with
weight 0. This is a minor nuisance, because a branch with weight 0 is
different to "don't have information". In the context of
instrumentation, it may mean "never executed", in the context of
sampling, it means "never or seldom executed".

In allowing 0 weight branches, I ran into issues with the switch
expansion code in selection DAG. It is currently hardwired to not handle
branches with weight 0. To maintain the current behaviour, I changed it
to use 1 when it finds 0, but perhaps the algorithm needs changes to
tolerate branches with weight zero.

Reviewers: hansw

Subscribers: llvm-commits

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

llvm-svn: 236617

show more ...

Revert r236546, "propagate IR-level fast-math-flags to DAG nodes (NFC)"

It caused undefined behavior.

llvm-svn: 236600

[SelectionDAG] Move RegsForValue into SelectionDAGBuilder.h. NFC.

Summary:
The exported class will be used in later change, in
StatepointLowering.cpp. It is still internal to SelectionDAG (not
expo

[SelectionDAG] Move RegsForValue into SelectionDAGBuilder.h. NFC.

Summary:
The exported class will be used in later change, in
StatepointLowering.cpp. It is still internal to SelectionDAG (not
exported via include/).

Reviewers: reames, atrick

Subscribers: llvm-commits

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

llvm-svn: 236554

show more ...

[SelectionDAG] Pass explicit type to lowerCallOperands. NFC.

Summary:
Currently this does not change anything, but change will be used in a
later change to StatepointLowering.cpp

Reviewers: reames,

[SelectionDAG] Pass explicit type to lowerCallOperands. NFC.

Summary:
Currently this does not change anything, but change will be used in a
later change to StatepointLowering.cpp

Reviewers: reames, atrick

Subscribers: llvm-commits

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

llvm-svn: 236553

show more ...

propagate IR-level fast-math-flags to DAG nodes (NFC)

This patch adds the minimum plumbing necessary to use IR-level
fast-math-flags (FMF) in the backend without actually using
them for anything yet

propagate IR-level fast-math-flags to DAG nodes (NFC)

This patch adds the minimum plumbing necessary to use IR-level
fast-math-flags (FMF) in the backend without actually using
them for anything yet. This is a follow-on to:
http://reviews.llvm.org/rL235997

...which split the existing nsw / nuw / exact flags and FMF
into their own struct.

There are 2 structural changes here:

1. The main diff is that we're preparing to extend the optimization
flags to affect more than just binary SDNodes. Eg, IR intrinsics
( https://llvm.org/bugs/show_bug.cgi?id=21290 ) or non-binop nodes
that don't even exist in IR such as FMA, FNEG, etc.

2. The other change is that we're actually copying the FP fast-math-flags
from the IR instructions to SDNodes.

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

llvm-svn: 236546

show more ...

Inline local variable to silence unused warning.

llvm-svn: 236212

Switch lowering: use profile info to build weight-balanced binary search trees

This will cause hot nodes to appear closer to the root.

The literature says building the tree like this makes it a nea

Switch lowering: use profile info to build weight-balanced binary search trees

This will cause hot nodes to appear closer to the root.

The literature says building the tree like this makes it a near-optimal (in
terms of search time given key frequencies) binary search tree. In LLVM's case,
we can do up to 3 comparisons in each leaf node, so it might be better to opt
for lower tree height in some cases; that's something to look into in the
future.

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

llvm-svn: 236192

show more ...

IR: Give 'DI' prefix to debug info metadata

Finish off PR23080 by renaming the debug info IR constructs from `MD*`
to `DI*`. The last of the `DIDescriptor` classes were deleted in
r235356, and the

IR: Give 'DI' prefix to debug info metadata

Finish off PR23080 by renaming the debug info IR constructs from `MD*`
to `DI*`. The last of the `DIDescriptor` classes were deleted in
r235356, and the last of the related typedefs removed in r235413, so
this has all baked for about a week.

Note: If you have out-of-tree code (like a frontend), I recommend that
you get everything compiling and tests passing with the *previous*
commit before updating to this one. It'll be easier to keep track of
what code is using the `DIDescriptor` hierarchy and what you've already
updated, and I think you're extremely unlikely to insert bugs. YMMV of
course.

Back to *this* commit: I did this using the rename-md-di-nodes.sh
upgrade script I've attached to PR23080 (both code and testcases) and
filtered through clang-format-diff.py. I edited the tests for
test/Assembler/invalid-generic-debug-node-*.ll by hand since the columns
were off-by-three. It should work on your out-of-tree testcases (and
code, if you've followed the advice in the previous paragraph).

Some of the tests are in badly named files now (e.g.,
test/Assembler/invalid-mdcompositetype-missing-tag.ll should be
'dicompositetype'); I'll come back and move the files in a follow-up
commit.

llvm-svn: 236120

show more ...

Fixed masked gather/scatter switch-case

llvm-svn: 236092

fixed comments, blanks, nullptr; NFC

llvm-svn: 236086

Reapply r235977 "[DebugInfo] Add debug locations to constant SD nodes"

[DebugInfo] Add debug locations to constant SD nodes

This adds debug location to constant nodes of Selection DAG and updates
a

Reapply r235977 "[DebugInfo] Add debug locations to constant SD nodes"

[DebugInfo] Add debug locations to constant SD nodes

This adds debug location to constant nodes of Selection DAG and updates
all places that create constants to pass debug locations
(see PR13269).

Can't guarantee that all locations are correct, but in a lot of cases choice
is obvious, so most of them should be. At least all tests pass.

Tests for these changes do not cover everything, instead just check it for
SDNodes, ARM and AArch64 where it's easy to get incorrect locations on
constants.

This is not complete fix as FastISel contains workaround for wrong debug
locations, which drops locations from instructions on processing constants,
but there isn't currently a way to use debug locations from constants there
as llvm::Constant doesn't cache it (yet). Although this is a bit different
issue, not directly related to these changes.

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

llvm-svn: 235989

show more ...

Revert "[DebugInfo] Add debug locations to constant SD nodes"

This breaks a test:
http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/23870

llvm-svn: 235987

[DebugInfo] Add debug locations to constant SD nodes

This adds debug location to constant nodes of Selection DAG and updates
all places that create constants to pass debug locations
(see PR13269).

[DebugInfo] Add debug locations to constant SD nodes

This adds debug location to constant nodes of Selection DAG and updates
all places that create constants to pass debug locations
(see PR13269).

Can't guarantee that all locations are correct, but in a lot of cases choice
is obvious, so most of them should be. At least all tests pass.

Tests for these changes do not cover everything, instead just check it for
SDNodes, ARM and AArch64 where it's easy to get incorrect locations on
constants.

This is not complete fix as FastISel contains workaround for wrong debug
locations, which drops locations from instructions on processing constants,
but there isn't currently a way to use debug locations from constants there
as llvm::Constant doesn't cache it (yet). Although this is a bit different
issue, not directly related to these changes.

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

llvm-svn: 235977

show more ...