Reapply "[Intrinsics] Add `nocallback` to the default intrinsic attributes"

This reverts commit c5f789050daab25aad6770790987e2b7c0395936 and
reapplies 7aea3ea8c3b33c9bb338d5d6c0e4832be1d09ac3 with a

Reapply "[Intrinsics] Add `nocallback` to the default intrinsic attributes"

This reverts commit c5f789050daab25aad6770790987e2b7c0395936 and
reapplies 7aea3ea8c3b33c9bb338d5d6c0e4832be1d09ac3 with additional test
changes.

show more ...

[IR] Rename `comdat noduplicates` to `comdat nodeduplicate`

In the textual format, `noduplicates` means no COMDAT/section group
deduplication is performed. Therefore, if both sets of sections are re

[IR] Rename `comdat noduplicates` to `comdat nodeduplicate`

In the textual format, `noduplicates` means no COMDAT/section group
deduplication is performed. Therefore, if both sets of sections are retained, and
they happen to define strong external symbols with the same names,
there will be a duplicate definition linker error.

In PE/COFF, the selection kind lowers to `IMAGE_COMDAT_SELECT_NODUPLICATES`.
The name describes the corollary instead of the immediate semantics. The name
can cause confusion to other binary formats (ELF, wasm) which have implemented/
want to implement the "no deduplication" selection kind. Rename it to be clearer.

Reviewed By: rnk

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

show more ...

Reapply "OpaquePtr: Turn inalloca into a type attribute"

This reverts commit 07e46367baeca96d84b03fa215b41775f69d5989.

Revert "Reapply "OpaquePtr: Turn inalloca into a type attribute""

Reverting because test 'Bindings/Go/go.test' is failing on most
buildbots.

This reverts commit fc9df309917e57de704f3ce4372138a8d4a2

Revert "Reapply "OpaquePtr: Turn inalloca into a type attribute""

Reverting because test 'Bindings/Go/go.test' is failing on most
buildbots.

This reverts commit fc9df309917e57de704f3ce4372138a8d4a23d7a.

show more ...

Reapply "OpaquePtr: Turn inalloca into a type attribute"

This reverts commit 20d5c42e0ef5d252b434bcb610b04f1cb79fe771.

Revert "OpaquePtr: Turn inalloca into a type attribute"

This reverts commit 4fefed65637ec46c8c2edad6b07b5569ac61e9e5.
Broke check-clang everywhere.

OpaquePtr: Turn inalloca into a type attribute

I think byval/sret and the others are close to being able to rip out
the code to support the missing type case. A lot of this code is
shared with inall

OpaquePtr: Turn inalloca into a type attribute

I think byval/sret and the others are close to being able to rip out
the code to support the missing type case. A lot of this code is
shared with inalloca, so catch this up to the others so that can
happen.

show more ...

OpaquePtr: Bulk update tests to use typed sret

OpaquePtr: Bulk update tests to use typed byval

Upgrade of the IR text tests should be the only thing blocking making
typed byval mandatory. Partially done through regex and partially
manual.

[IR] Make nosync, nofree and willreturn default for intrinsics.

D70365 allows us to make attributes default. This is a follow up to
actually make nosync, nofree and willreturn default. The approach

[IR] Make nosync, nofree and willreturn default for intrinsics.

D70365 allows us to make attributes default. This is a follow up to
actually make nosync, nofree and willreturn default. The approach we
chose, for now, is to opt-in to default attributes to avoid introducing
problems to target specific intrinsics. Intrinsics with default
attributes can be created using `DefaultAttrsIntrinsic` class.

show more ...

Reapply "OpaquePtr: Add type to sret attribute"

This reverts commit eb9f7c28e5fe6d75fed3587023e17f2997c8024b.

Previously this was incorrectly handling linking of the contained
type, so this merges

Reapply "OpaquePtr: Add type to sret attribute"

This reverts commit eb9f7c28e5fe6d75fed3587023e17f2997c8024b.

Previously this was incorrectly handling linking of the contained
type, so this merges the fixes from D88973.

show more ...

Revert "OpaquePtr: Add type to sret attribute"

This reverts commit 55c4ff91bd820d72014f63dcf7f3d5a0d3397986.

Issues were introduced as discussed in https://reviews.llvm.org/D88241
where this change

Revert "OpaquePtr: Add type to sret attribute"

This reverts commit 55c4ff91bd820d72014f63dcf7f3d5a0d3397986.

Issues were introduced as discussed in https://reviews.llvm.org/D88241
where this change made previous bugs in the linker and BitCodeWriter
visible.

show more ...

OpaquePtr: Add type to sret attribute

Make the corresponding change that was made for byval in
b7141207a483d39b99c2b4da4eb3bb591eca9e1a. Like byval, this requires a
bulk update of the test IR tests

OpaquePtr: Add type to sret attribute

Make the corresponding change that was made for byval in
b7141207a483d39b99c2b4da4eb3bb591eca9e1a. Like byval, this requires a
bulk update of the test IR tests to include the type before this can
be mandatory.

show more ...

[FunctionAttrs] Annotate "willreturn" for intrinsics

Summary:
In D62801, new function attribute `willreturn` was introduced. In short, a function with `willreturn` is guaranteed to come back to the

[FunctionAttrs] Annotate "willreturn" for intrinsics

Summary:
In D62801, new function attribute `willreturn` was introduced. In short, a function with `willreturn` is guaranteed to come back to the call site(more precise definition is in LangRef).

In this patch, willreturn is annotated for LLVM intrinsics.

Reviewers: jdoerfert

Reviewed By: jdoerfert

Subscribers: jvesely, nhaehnle, sstefan1, llvm-commits

Tags: #llvm

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

llvm-svn: 367184

show more ...

Allow prefetching from non-zero address spaces

Summary:
This is useful for targets which have prefetch instructions for non-default address spaces.

<rdar://problem/42662136>

Subscribers: nemanjai,

Allow prefetching from non-zero address spaces

Summary:
This is useful for targets which have prefetch instructions for non-default address spaces.

<rdar://problem/42662136>

Subscribers: nemanjai, javed.absar, hiraditya, kbarton, jkorous, dexonsmith, cfe-commits, llvm-commits, RKSimon, hfinkel, t.p.northover, craig.topper, anemet

Tags: #clang, #llvm

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

llvm-svn: 367032

show more ...

Added address-space mangling for stack related intrinsics

Modified the following 3 intrinsics:
int_addressofreturnaddress,
int_frameaddress & int_sponentry.

Reviewed By: arsenm

Differential Revisi

Added address-space mangling for stack related intrinsics

Modified the following 3 intrinsics:
int_addressofreturnaddress,
int_frameaddress & int_sponentry.

Reviewed By: arsenm

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

llvm-svn: 366679

show more ...

Reapply: IR: add optional type to 'byval' function parameters

When we switch to opaque pointer types we will need some way to describe
how many bytes a 'byval' parameter should occupy on the stack.

Reapply: IR: add optional type to 'byval' function parameters

When we switch to opaque pointer types we will need some way to describe
how many bytes a 'byval' parameter should occupy on the stack. This adds
a (for now) optional extra type parameter.

If present, the type must match the pointee type of the argument.

The original commit did not remap byval types when linking modules, which broke
LTO. This version fixes that.

Note to front-end maintainers: if this causes test failures, it's probably
because the "byval" attribute is printed after attributes without any parameter
after this change.

llvm-svn: 362128

show more ...

Revert "IR: add optional type to 'byval' function parameters"

The IRLinker doesn't delve into the new byval attribute when mapping types, and
this breaks LTO.

llvm-svn: 362029

IR: add optional type to 'byval' function parameters

When we switch to opaque pointer types we will need some way to describe
how many bytes a 'byval' parameter should occupy on the stack. This adds

IR: add optional type to 'byval' function parameters

When we switch to opaque pointer types we will need some way to describe
how many bytes a 'byval' parameter should occupy on the stack. This adds
a (for now) optional extra type parameter.

If present, the type must match the pointee type of the argument.

Note to front-end maintainers: if this causes test failures, it's probably
because the "byval" attribute is printed after attributes without any parameter
after this change.

llvm-svn: 362012

show more ...

bitcode support change for fast flags compatibility

Summary: The discussion and as per need, each vendor needs a way to keep the old fast flags and the new fast flags in the auto upgrade path of the

bitcode support change for fast flags compatibility

Summary: The discussion and as per need, each vendor needs a way to keep the old fast flags and the new fast flags in the auto upgrade path of the IR upgrader. This revision addresses that issue.

Patched by Michael Berg

Reviewers: qcolombet, hans, steven_wu

Reviewed By: qcolombet, steven_wu

Subscribers: dexonsmith, vsk, mehdi_amini, andrewrk, MatzeB, wristow, spatel

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

llvm-svn: 325525

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 ...

[AArch64] Extend CallingConv::X86_64_Win64 to AArch64 as well

Rename the enum value from X86_64_Win64 to plain Win64.

The symbol exposed in the textual IR is changed from 'x86_64_win64cc'
to 'win64

[AArch64] Extend CallingConv::X86_64_Win64 to AArch64 as well

Rename the enum value from X86_64_Win64 to plain Win64.

The symbol exposed in the textual IR is changed from 'x86_64_win64cc'
to 'win64cc', but the numeric value is kept, keeping support for
old bitcode.

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

llvm-svn: 308208

show more ...

Enhance synchscope representation

OpenCL 2.0 introduces the notion of memory scopes in atomic operations to
global and local memory. These scopes restrict how synchronization is
achieved, whic

Enhance synchscope representation

OpenCL 2.0 introduces the notion of memory scopes in atomic operations to
global and local memory. These scopes restrict how synchronization is
achieved, which can result in improved performance.

This change extends existing notion of synchronization scopes in LLVM to
support arbitrary scopes expressed as target-specific strings, in addition to
the already defined scopes (single thread, system).

The LLVM IR and MIR syntax for expressing synchronization scopes has changed
to use *syncscope("<scope>")*, where <scope> can be "singlethread" (this
replaces *singlethread* keyword), or a target-specific name. As before, if
the scope is not specified, it defaults to CrossThread/System scope.

Implementation details:
- Mapping from synchronization scope name/string to synchronization scope id
is stored in LLVM context;
- CrossThread/System and SingleThread scopes are pre-defined to efficiently
check for known scopes without comparing strings;
- Synchronization scope names are stored in SYNC_SCOPE_NAMES_BLOCK in
the bitcode.

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

llvm-svn: 307722

show more ...

Change the default attributes for llvm.prefetch to inaccessiblemem_or_argmemonly
so that we can perform some optimizations across it.

Fixes PR32365

llvm-svn: 298781

Sort the enums in Attributes.h in case insensitive alphabetical order.

Sort the enums in preparation for moving the attributes to a table-gen
file.

rdar://problem/19836465

llvm-svn: 252692