Move floating point related entities to namespace level

Enumerations that describe rounding mode and exception behavior were
defined inside ConstrainedFPIntrinsic. It makes sense to use the same
def

Move floating point related entities to namespace level

Enumerations that describe rounding mode and exception behavior were
defined inside ConstrainedFPIntrinsic. It makes sense to use the same
definitions to represent the same properties in other cases, not only
in constrained intrinsics. It was however inconvenient as required to
include constrained intrinsics definitions even if they were not needed.
Also using long scope prefix reduced readability.

This change moves these definitioins to the namespace llvm::fp.
No functional changes.

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

show more ...

[FPEnv] Teach the IRBuilder about correct use of the strictfp attribute.

The IRBuilder needs to add the strictfp attribute to function
definitions and calls when constrained floating point is enable

[FPEnv] Teach the IRBuilder about correct use of the strictfp attribute.

The IRBuilder needs to add the strictfp attribute to function
definitions and calls when constrained floating point is enabled.

Since so far all front ends have had to do is flip the constrained
switch, I've made this patch always add the required attributes
when said constrained switch is enabled. This continues to keep
changes to front ends minimal.

Differential Revision: D69312

show more ...

[IR] Reimplement FPMathOperator::classof as a whitelist.

Summary:
This makes it much easier to verify that the implementation matches the
documentation. It uncovered a bug in the unit tests where we

[IR] Reimplement FPMathOperator::classof as a whitelist.

Summary:
This makes it much easier to verify that the implementation matches the
documentation. It uncovered a bug in the unit tests where we were
accidentally setting fast math flags on a load instruction.

Reviewers: spatel, wristow, arsenm, hfinkel, aemerson, efriedma, cameron.mcinally, mcberg2017, jmolloy

Subscribers: wdng, llvm-commits

Tags: #llvm

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

llvm-svn: 375252

show more ...

[FPEnv] Teach the IRBuilder about constrained FPToSI and FPToUI.

The IRBuilder doesn't know that the two floating point to integer instructions
have constrained equivalents. This patch adds the supp

[FPEnv] Teach the IRBuilder about constrained FPToSI and FPToUI.

The IRBuilder doesn't know that the two floating point to integer instructions
have constrained equivalents. This patch adds the support by building on
the strict FP mode now present in the IRBuilder.

Reviewed by: John McCall
Approved by: John McCall
Differential Revision: https://reviews.llvm.org/D67291

llvm-svn: 371235

show more ...

[IntrinsicEmitter] Support scalable vectors in intrinsics

Summary:
This patch adds support for scalable vectors in intrinsics, enabling
intrinsics such as the following to be defined:

declare <

[IntrinsicEmitter] Support scalable vectors in intrinsics

Summary:
This patch adds support for scalable vectors in intrinsics, enabling
intrinsics such as the following to be defined:

declare <vscale x 4 x i32> @llvm.something.nxv4i32(<vscale x 4 x i32>)

Support for this is implemented by defining a new type descriptor for
scalable vectors and adding mangling support for scalable vector types
in the name mangling scheme used by 'any' types in intrinsic signatures.

Tests have been added for IRBuilder to test scalable vectors work as
expected when using intrinsics through this interface. This required
implementing an intrinsic that is explicitly defined with scalable
vectors, e.g. LLVMType<nxv4i32>, an SVE floating-point convert
intrinsic was used for this. The behaviour of the overloaded type
LLVMScalarOrSameVectorWidth with scalable vectors is tested using the
existing masked load intrinsic. Also added an .ll test to test the
Verifier catches a bad intrinsic argument when passing a fixed-width
predicate (mask) to the masked.load intrinsic where a scalable is
expected.

Patch by Paul Walker

Reviewed By: sdesmalen

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

llvm-svn: 370053

show more ...

Added unit tests to check supported rounding modes

Also added fixed misspelled metadata name.

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

llvm-svn: 368650

[FPEnv] Teach the IRBuilder about constrained FPTrunc and FPExt

The IRBuilder doesn't know that FPTrunc and FPExt have constrained
equivalents. Add the support by building on the strict FP mode now

[FPEnv] Teach the IRBuilder about constrained FPTrunc and FPExt

The IRBuilder doesn't know that FPTrunc and FPExt have constrained
equivalents. Add the support by building on the strict FP mode now
present in the IRBuilder.

Reviewed by: John McCall
Approved by: John McCall
Differential Revision: https://reviews.llvm.org/D64934

llvm-svn: 366477

show more ...

OpaquePtr: pass type to CreateLoad. NFC.

This is the one place in LLVM itself that used the deprecated API for
CreateLoad, so I just added the type in.

llvm-svn: 365472

Teach the IRBuilder about fadd and friends.

The IRBuilder has calls to create floating point instructions like fadd.
It does not have calls to create constrained versions of them. This patch
adds su

Teach the IRBuilder about fadd and friends.

The IRBuilder has calls to create floating point instructions like fadd.
It does not have calls to create constrained versions of them. This patch
adds support for constrained creation of fadd, fsub, fmul, fdiv, and frem.

Reviewed by: John McCall, Sanjay Patel
Approved by: John McCall
Differential Revision: https://reviews.llvm.org/D53157

llvm-svn: 365339

show more ...

[IRBuilder] Add CreateFNegFMF(...) to the IRBuilder

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

llvm-svn: 362947

[IRBuilder] Add CreateUnOp(...) to the IRBuilder to support unary FNeg

Also update UnaryOperator to support isa, cast, and dyn_cast.

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

llvm-svn

[IRBuilder] Add CreateUnOp(...) to the IRBuilder to support unary FNeg

Also update UnaryOperator to support isa, cast, and dyn_cast.

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

llvm-svn: 361816

show more ...

Test commit access [NFC]

Remove a trailing space

llvm-svn: 358648

[opaque pointer types] Pass value type to LoadInst creation.

This cleans up all LoadInst creation in LLVM to explicitly pass the
value type rather than deriving it from the pointer's element-type.

[opaque pointer types] Pass value type to LoadInst creation.

This cleans up all LoadInst creation in LLVM to explicitly pass the
value type rather than deriving it from the pointer's element-type.

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

llvm-svn: 352911

show more ...

[opaque pointer types] Pass function types to CallInst creation.

This cleans up all CallInst creation in LLVM to explicitly pass a
function type rather than deriving it from the pointer's element-ty

[opaque pointer types] Pass function types to CallInst creation.

This cleans up all CallInst creation in LLVM to explicitly pass a
function type rather than deriving it from the pointer's element-type.

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

llvm-svn: 352909

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[DebugInfo] DISubprogram flags get their own flags word. NFC.
This will hold flags specific to subprograms. In the future
we could potentially free up scarce bits in DIFlags by moving
subprogram-spec

[DebugInfo] DISubprogram flags get their own flags word. NFC.
This will hold flags specific to subprograms. In the future
we could potentially free up scarce bits in DIFlags by moving
subprogram-specific flags from there to the new flags word.

This patch does not change IR/bitcode formats, that will be
done in a follow-up.

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

llvm-svn: 347239

show more ...

[TI removal] Make `getTerminator()` return a generic `Instruction`.

This removes the primary remaining API producing `TerminatorInst` which
will reduce the rate at which code is introduced trying to

[TI removal] Make `getTerminator()` return a generic `Instruction`.

This removes the primary remaining API producing `TerminatorInst` which
will reduce the rate at which code is introduced trying to use it and
generally make it much easier to remove the remaining APIs across the
codebase.

Also clean up some of the stragglers that the previous mechanical update
of variables missed.

Users of LLVM and out-of-tree code generally will need to update any
explicit variable types to handle this. Replacing `TerminatorInst` with
`Instruction` (or `auto`) almost always works. Most of these edits were
made in prior commits using the perl one-liner:
```
perl -i -ple 's/TerminatorInst(\b.* = .*getTerminator\(\))/Instruction\1/g'
```

This also my break some rare use cases where people overload for both
`Instruction` and `TerminatorInst`, but these should be easily fixed by
removing the `TerminatorInst` overload.

llvm-svn: 344504

show more ...

[Intrinsic] Add llvm.minimum and llvm.maximum instrinsic functions

Summary:
These new intrinsics have the semantics of the `minimum` and `maximum`
operations specified by the latest draft of IEEE 75

[Intrinsic] Add llvm.minimum and llvm.maximum instrinsic functions

Summary:
These new intrinsics have the semantics of the `minimum` and `maximum`
operations specified by the latest draft of IEEE 754-2018. Unlike
llvm.minnum and llvm.maxnum, these new intrinsics propagate NaNs and
always treat -0.0 as less than 0.0. `minimum` and `maximum` lower
directly to the existing `fminnan` and `fmaxnan` ISel DAG nodes. It is
safe to reuse these DAG nodes because before this patch were only
emitted in situations where there were known to be no NaN arguments or
where NaN propagation was correct and there were known to be no zero
arguments. I know of only four backends that lower fminnan and
fmaxnan: WebAssembly, ARM, AArch64, and SystemZ, and each of these
lowers fminnan and fmaxnan to instructions that are compatible with
the IEEE 754-2018 semantics.

Reviewers: aheejin, dschuff, sunfish, javed.absar

Subscribers: kristof.beyls, dexonsmith, kristina, llvm-commits

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

llvm-svn: 344437

show more ...

[IRBuilder] Fixup CreateIntrinsic to allow specifying Types to Mangle.

The IRBuilder CreateIntrinsic method wouldn't allow you to specify the
types that you wanted the intrinsic to be mangled with.

[IRBuilder] Fixup CreateIntrinsic to allow specifying Types to Mangle.

The IRBuilder CreateIntrinsic method wouldn't allow you to specify the
types that you wanted the intrinsic to be mangled with. To fix this
I've:

- Added an ArrayRef<Type *> member to both CreateIntrinsic overloads.
- Used that array to pass into the Intrinsic::getDeclaration call.
- Added a CreateUnaryIntrinsic to replace the most common use of
CreateIntrinsic where the type was auto-deduced from operand 0.
- Added a bunch more unit tests to test Create*Intrinsic calls that
weren't being tested (including the FMF flag that wasn't checked).

This was suggested as part of the AMDGPU specific atomic optimizer
review (https://reviews.llvm.org/D51969).

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

llvm-svn: 343962

show more ...

[DebugInfo] Refactoring DIType::setFlags to DIType::cloneWithFlags, NFC

and using the latter in DIBuilder::createArtificialType and
DIBuilder::createObjectPointerType methods as well as introducing

[DebugInfo] Refactoring DIType::setFlags to DIType::cloneWithFlags, NFC

and using the latter in DIBuilder::createArtificialType and
DIBuilder::createObjectPointerType methods as well as introducing
mirroring DISubprogram::cloneWithFlags and
DIBuilder::createArtificialSubprogram methods.

The primary goal here is to add createArtificialSubprogram to support
a pass downstream while keeping the method consistent with the
existing ones and making sure we don't encourage changing already
created DI-nodes.

Reviewed By: aprantl

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

llvm-svn: 333806

show more ...

IRBuilder: Add overload for intrinsics without args

llvm-svn: 333443

[IRBuilder] fix CreateMaxNum to actually produce maxnum (PR36454)

The bug was introduced here:
https://reviews.llvm.org/rL296409
...but the patch doesn't use maxnum and nothing else in
trunk has tr

[IRBuilder] fix CreateMaxNum to actually produce maxnum (PR36454)

The bug was introduced here:
https://reviews.llvm.org/rL296409
...but the patch doesn't use maxnum and nothing else in
trunk has tried since then, so the bug went unnoticed.

llvm-svn: 325607

show more ...

[IR] redefine 'UnsafeAlgebra' / 'reassoc' fast-math-flags and add 'trans' fast-math-flag

As discussed on llvm-dev:
http://lists.llvm.org/pipermail/llvm-dev/2016-November/107104.html
and again more r

[IR] redefine 'UnsafeAlgebra' / 'reassoc' fast-math-flags and add 'trans' fast-math-flag

As discussed on llvm-dev:
http://lists.llvm.org/pipermail/llvm-dev/2016-November/107104.html
and again more recently:
http://lists.llvm.org/pipermail/llvm-dev/2017-October/118118.html

...this is a step in cleaning up our fast-math-flags implementation in IR to better match
the capabilities of both clang's user-visible flags and the backend's flags for SDNode.

As proposed in the above threads, we're replacing the 'UnsafeAlgebra' bit (which had the
'umbrella' meaning that all flags are set) with a new bit that only applies to algebraic
reassociation - 'AllowReassoc'.

We're also adding a bit to allow approximations for library functions called 'ApproxFunc'
(this was initially proposed as 'libm' or similar).

...and we're out of bits. 7 bits ought to be enough for anyone, right? :) FWIW, I did
look at getting this out of SubclassOptionalData via SubclassData (spacious 16-bits),
but that's apparently already used for other purposes. Also, I don't think we can just
add a field to FPMathOperator because Operator is not intended to be instantiated.
We'll defer movement of FMF to another day.

We keep the 'fast' keyword. I thought about removing that, but seeing IR like this:
%f.fast = fadd reassoc nnan ninf nsz arcp contract afn float %op1, %op2
...made me think we want to keep the shortcut synonym.

Finally, this change is binary incompatible with existing IR as seen in the
compatibility tests. This statement:
"Newer releases can ignore features from older releases, but they cannot miscompile
them. For example, if nsw is ever replaced with something else, dropping it would be
a valid way to upgrade the IR."
( http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility )
...provides the flexibility we want to make this change without requiring a new IR
version. Ie, we're not loosening the FP strictness of existing IR. At worst, we will
fail to optimize some previously 'fast' code because it's no longer recognized as
'fast'. This should get fixed as we audit/squash all of the uses of 'isFast()'.

Note: an inter-dependent clang commit to use the new API name should closely follow
commit.

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

llvm-svn: 317488

show more ...

Debug Info: Add a file: field to DIImportedEntity.

DIImportedEntity has a line number, but not a file field. To determine
the decl_line/decl_file we combine the line number from the
DIImportedEntity

Debug Info: Add a file: field to DIImportedEntity.

DIImportedEntity has a line number, but not a file field. To determine
the decl_line/decl_file we combine the line number from the
DIImportedEntity with the file from the DIImportedEntity's scope. This
does not work correctly when the parent scope is a DINamespace or a
DIModule, both of which do not have a source file.

This patch adds a file field to DIImportedEntity to unambiguously
identify the source location of the using/import declaration. Most
testcase updates are mechanical, the interesting one is the removal of
the FIXME in test/DebugInfo/Generic/namespace.ll.

This fixes PR33822. See https://bugs.llvm.org/show_bug.cgi?id=33822
for more context.

<rdar://problem/33357889>
https://bugs.llvm.org/show_bug.cgi?id=33822

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

llvm-svn: 308398

show more ...

Re-sort #include lines for unittests. This uses a slightly modified
clang-format (https://reviews.llvm.org/D33932) to keep primary headers
at the top and handle new utility headers like 'gmock' consi

Re-sort #include lines for unittests. This uses a slightly modified
clang-format (https://reviews.llvm.org/D33932) to keep primary headers
at the top and handle new utility headers like 'gmock' consistently with
other utility headers.

No other change was made. I did no manual edits, all of this is
clang-format.

This should allow other changes to have more clear and focused diffs,
and is especially motivated by moving some headers into more focused
libraries.

llvm-svn: 304786

show more ...