2019-02-05 20:05:53 +08:00
|
|
|
// RUN: %clang_cc1 -std=c++14 -triple x86_64-unknown-unknown %s -emit-llvm -o - | FileCheck %s
|
2011-05-16 09:05:12 +08:00
|
|
|
|
|
|
|
|
typedef __typeof__(sizeof(0)) size_t;
|
2009-06-01 04:21:44 +08:00
|
|
|
|
2014-06-05 08:43:02 +08:00
|
|
|
// Declare an 'operator new' template to tickle a bug in __builtin_operator_new.
|
|
|
|
|
template<typename T> void *operator new(size_t, int (*)(T));
|
|
|
|
|
|
2013-07-22 07:12:18 +08:00
|
|
|
// Ensure that this declaration doesn't cause operator new to lose its
|
|
|
|
|
// 'noalias' attribute.
|
|
|
|
|
void *operator new[](size_t);
|
|
|
|
|
|
2009-06-01 04:21:44 +08:00
|
|
|
void t1() {
|
2013-07-22 07:12:18 +08:00
|
|
|
delete new int;
|
|
|
|
|
delete [] new int [3];
|
|
|
|
|
}
|
|
|
|
|
|
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
|
|
|
// CHECK: declare nonnull i8* @_Znwm(i64) [[ATTR_NOBUILTIN:#[^ ]*]]
|
2013-07-22 07:12:18 +08:00
|
|
|
// CHECK: declare void @_ZdlPv(i8*) [[ATTR_NOBUILTIN_NOUNWIND:#[^ ]*]]
|
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
|
|
|
// CHECK: declare nonnull i8* @_Znam(i64) [[ATTR_NOBUILTIN]]
|
2013-07-22 07:12:18 +08:00
|
|
|
// CHECK: declare void @_ZdaPv(i8*) [[ATTR_NOBUILTIN_NOUNWIND]]
|
|
|
|
|
|
|
|
|
|
namespace std {
|
|
|
|
|
struct nothrow_t {};
|
2009-06-01 04:21:44 +08:00
|
|
|
}
|
2013-07-22 07:12:18 +08:00
|
|
|
std::nothrow_t nothrow;
|
2009-06-01 04:26:12 +08:00
|
|
|
|
2011-05-16 09:05:12 +08:00
|
|
|
// Declare the reserved placement operators.
|
|
|
|
|
void *operator new(size_t, void*) throw();
|
|
|
|
|
void operator delete(void*, void*) throw();
|
|
|
|
|
void *operator new[](size_t, void*) throw();
|
|
|
|
|
void operator delete[](void*, void*) throw();
|
2009-06-01 04:26:12 +08:00
|
|
|
|
2013-07-22 07:12:18 +08:00
|
|
|
// Declare the replaceable global allocation operators.
|
|
|
|
|
void *operator new(size_t, const std::nothrow_t &) throw();
|
|
|
|
|
void *operator new[](size_t, const std::nothrow_t &) throw();
|
|
|
|
|
void operator delete(void *, const std::nothrow_t &) throw();
|
|
|
|
|
void operator delete[](void *, const std::nothrow_t &) throw();
|
|
|
|
|
|
2015-02-14 09:52:20 +08:00
|
|
|
// Declare some other placemenet operators.
|
|
|
|
|
void *operator new(size_t, void*, bool) throw();
|
|
|
|
|
void *operator new[](size_t, void*, bool) throw();
|
|
|
|
|
|
2009-06-01 04:26:12 +08:00
|
|
|
void t2(int* a) {
|
|
|
|
|
int* b = new (a) int;
|
|
|
|
|
}
|
2009-06-01 04:56:36 +08:00
|
|
|
|
2009-06-01 05:12:26 +08:00
|
|
|
struct S {
|
|
|
|
|
int a;
|
|
|
|
|
};
|
|
|
|
|
|
2009-06-01 05:53:59 +08:00
|
|
|
// POD types.
|
2009-06-01 04:56:36 +08:00
|
|
|
void t3() {
|
|
|
|
|
int *a = new int(10);
|
2009-06-01 05:07:58 +08:00
|
|
|
_Complex int* b = new _Complex int(10i);
|
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
|
|
|
|
2009-06-01 05:12:26 +08:00
|
|
|
S s;
|
|
|
|
|
s.a = 10;
|
|
|
|
|
S *sp = new S(s);
|
2009-06-01 04:56:36 +08:00
|
|
|
}
|
2009-06-01 05:53:59 +08:00
|
|
|
|
|
|
|
|
// Non-POD
|
|
|
|
|
struct T {
|
|
|
|
|
T();
|
|
|
|
|
int a;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
void t4() {
|
2009-09-24 00:07:23 +08:00
|
|
|
// CHECK: call void @_ZN1TC1Ev
|
2009-06-01 05:53:59 +08:00
|
|
|
T *t = new T;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct T2 {
|
|
|
|
|
int a;
|
|
|
|
|
T2(int, int);
|
|
|
|
|
};
|
|
|
|
|
|
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
|
|
|
void t5() {
|
2009-09-24 00:07:23 +08:00
|
|
|
// CHECK: call void @_ZN2T2C1Eii
|
2009-06-01 05:53:59 +08:00
|
|
|
T2 *t2 = new T2(10, 10);
|
|
|
|
|
}
|
2009-06-01 08:05:16 +08:00
|
|
|
|
|
|
|
|
int *t6() {
|
|
|
|
|
// Null check.
|
|
|
|
|
return new (0) int(10);
|
|
|
|
|
}
|
2009-06-01 08:26:14 +08:00
|
|
|
|
|
|
|
|
void t7() {
|
|
|
|
|
new int();
|
|
|
|
|
}
|
2009-09-24 00:07:23 +08:00
|
|
|
|
2009-09-24 02:59:48 +08:00
|
|
|
struct U {
|
|
|
|
|
~U();
|
|
|
|
|
};
|
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
|
|
|
|
2009-09-24 00:07:23 +08:00
|
|
|
void t8(int n) {
|
|
|
|
|
new int[10];
|
|
|
|
|
new int[n];
|
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
|
|
|
|
2009-09-24 00:07:23 +08:00
|
|
|
// Non-POD
|
|
|
|
|
new T[10];
|
|
|
|
|
new T[n];
|
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
|
|
|
|
2009-09-24 02:59:48 +08:00
|
|
|
// Cookie required
|
|
|
|
|
new U[10];
|
|
|
|
|
new U[n];
|
2009-09-24 00:07:23 +08:00
|
|
|
}
|
2009-11-23 03:25:33 +08:00
|
|
|
|
|
|
|
|
void t9() {
|
|
|
|
|
bool b;
|
|
|
|
|
|
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
|
|
|
new bool(true);
|
2009-11-23 03:25:33 +08:00
|
|
|
new (&b) bool(true);
|
|
|
|
|
}
|
2009-11-25 02:29:37 +08:00
|
|
|
|
|
|
|
|
struct A {
|
|
|
|
|
void* operator new(__typeof(sizeof(int)), int, float, ...);
|
|
|
|
|
A();
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
A* t10() {
|
|
|
|
|
// CHECK: @_ZN1AnwEmifz
|
|
|
|
|
return new(1, 2, 3.45, 100) A;
|
|
|
|
|
}
|
|
|
|
|
|
2020-02-04 02:09:39 +08:00
|
|
|
// CHECK-LABEL: define void @_Z3t11i
|
2010-05-03 09:20:20 +08:00
|
|
|
struct B { int a; };
|
2010-07-21 09:10:17 +08:00
|
|
|
struct Bmemptr { int Bmemptr::* memptr; int a; };
|
|
|
|
|
|
|
|
|
|
void t11(int n) {
|
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
|
|
|
// CHECK: call noalias nonnull i8* @_Znwm
|
2010-04-04 11:10:52 +08:00
|
|
|
// CHECK: call void @llvm.memset.p0i8.i64(
|
2009-12-16 14:57:54 +08:00
|
|
|
B* b = new B();
|
2010-07-21 09:10:17 +08:00
|
|
|
|
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
|
|
|
// CHECK: call noalias nonnull i8* @_Znam
|
2010-07-21 09:10:17 +08:00
|
|
|
// CHECK: {{call void.*llvm.memset.p0i8.i64.*i8 0, i64 %}}
|
|
|
|
|
B *b2 = new B[n]();
|
|
|
|
|
|
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
|
|
|
// CHECK: call noalias nonnull i8* @_Znam
|
2010-07-21 09:10:17 +08:00
|
|
|
// CHECK: call void @llvm.memcpy.p0i8.p0i8.i64
|
|
|
|
|
// CHECK: br
|
|
|
|
|
Bmemptr *b_memptr = new Bmemptr[n]();
|
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
|
|
|
|
2010-07-21 09:10:17 +08:00
|
|
|
// CHECK: ret void
|
2009-12-16 14:57:54 +08:00
|
|
|
}
|
2010-05-03 23:09:17 +08:00
|
|
|
|
|
|
|
|
struct Empty { };
|
|
|
|
|
|
|
|
|
|
// We don't need to initialize an empty class.
|
2020-02-04 02:09:39 +08:00
|
|
|
// CHECK-LABEL: define void @_Z3t12v
|
2010-05-03 23:09:17 +08:00
|
|
|
void t12() {
|
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
|
|
|
// CHECK: call noalias nonnull i8* @_Znam
|
2010-07-21 09:10:17 +08:00
|
|
|
// CHECK-NOT: br
|
2010-05-03 23:09:17 +08:00
|
|
|
(void)new Empty[10];
|
2010-07-21 09:10:17 +08:00
|
|
|
|
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
|
|
|
// CHECK: call noalias nonnull i8* @_Znam
|
2010-07-21 09:10:17 +08:00
|
|
|
// CHECK-NOT: br
|
|
|
|
|
(void)new Empty[10]();
|
|
|
|
|
|
|
|
|
|
// CHECK: ret void
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Zero-initialization
|
2020-02-04 02:09:39 +08:00
|
|
|
// CHECK-LABEL: define void @_Z3t13i
|
2010-07-21 09:10:17 +08:00
|
|
|
void t13(int n) {
|
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
|
|
|
// CHECK: call noalias nonnull i8* @_Znwm
|
2010-07-21 09:10:17 +08:00
|
|
|
// CHECK: store i32 0, i32*
|
|
|
|
|
(void)new int();
|
|
|
|
|
|
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
|
|
|
// CHECK: call noalias nonnull i8* @_Znam
|
2010-07-21 09:10:17 +08:00
|
|
|
// CHECK: {{call void.*llvm.memset.p0i8.i64.*i8 0, i64 %}}
|
|
|
|
|
(void)new int[n]();
|
|
|
|
|
|
|
|
|
|
// CHECK-NEXT: ret void
|
2010-05-03 23:09:17 +08:00
|
|
|
}
|
2010-08-26 07:14:56 +08:00
|
|
|
|
|
|
|
|
struct Alloc{
|
2010-08-26 23:23:38 +08:00
|
|
|
int x;
|
2010-08-26 07:14:56 +08:00
|
|
|
void* operator new[](size_t size);
|
|
|
|
|
void operator delete[](void* p);
|
2010-08-26 23:23:38 +08:00
|
|
|
~Alloc();
|
2010-08-26 07:14:56 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
void f() {
|
2010-08-26 23:23:38 +08:00
|
|
|
// CHECK: call i8* @_ZN5AllocnaEm(i64 808)
|
|
|
|
|
// CHECK: store i64 200
|
2010-09-02 17:58:18 +08:00
|
|
|
// CHECK: call void @_ZN5AllocD1Ev(
|
2010-08-26 07:14:56 +08:00
|
|
|
// CHECK: call void @_ZN5AllocdaEPv(i8*
|
|
|
|
|
delete[] new Alloc[10][20];
|
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
|
|
|
// CHECK: call noalias nonnull i8* @_Znwm
|
2010-09-03 07:24:14 +08:00
|
|
|
// CHECK: call void @_ZdlPv(i8*
|
|
|
|
|
delete new bool;
|
|
|
|
|
// CHECK: ret void
|
2010-08-26 07:14:56 +08:00
|
|
|
}
|
2011-05-16 09:05:12 +08:00
|
|
|
|
|
|
|
|
namespace test15 {
|
|
|
|
|
struct A { A(); ~A(); };
|
|
|
|
|
|
2020-02-04 02:09:39 +08:00
|
|
|
// CHECK-LABEL: define void @_ZN6test156test0aEPv(
|
2015-02-28 05:19:58 +08:00
|
|
|
// CHECK: [[P:%.*]] = load i8*, i8**
|
2015-02-14 09:52:20 +08:00
|
|
|
// CHECK-NOT: icmp eq i8* [[P]], null
|
|
|
|
|
// CHECK-NOT: br i1
|
2011-05-16 09:05:12 +08:00
|
|
|
// CHECK: [[T0:%.*]] = bitcast i8* [[P]] to [[A:%.*]]*
|
2018-10-15 23:43:00 +08:00
|
|
|
// CHECK-NEXT: call void @_ZN6test151AC1Ev([[A]]* [[T0]])
|
2015-02-14 09:52:20 +08:00
|
|
|
void test0a(void *p) {
|
2011-05-16 09:05:12 +08:00
|
|
|
new (p) A();
|
|
|
|
|
}
|
|
|
|
|
|
2020-02-04 02:09:39 +08:00
|
|
|
// CHECK-LABEL: define void @_ZN6test156test0bEPv(
|
2015-02-28 05:19:58 +08:00
|
|
|
// CHECK: [[P0:%.*]] = load i8*, i8**
|
2015-02-14 09:52:20 +08:00
|
|
|
// CHECK: [[P:%.*]] = call i8* @_ZnwmPvb(i64 1, i8* [[P0]]
|
2011-05-16 09:05:12 +08:00
|
|
|
// CHECK-NEXT: icmp eq i8* [[P]], null
|
|
|
|
|
// CHECK-NEXT: br i1
|
2015-02-14 09:52:20 +08:00
|
|
|
// CHECK: [[T0:%.*]] = bitcast i8* [[P]] to [[A:%.*]]*
|
2018-10-15 23:43:00 +08:00
|
|
|
// CHECK-NEXT: call void @_ZN6test151AC1Ev([[A]]* [[T0]])
|
2015-02-14 09:52:20 +08:00
|
|
|
void test0b(void *p) {
|
|
|
|
|
new (p, true) A();
|
|
|
|
|
}
|
|
|
|
|
|
2020-02-04 02:09:39 +08:00
|
|
|
// CHECK-LABEL: define void @_ZN6test156test1aEPv(
|
2015-02-28 05:19:58 +08:00
|
|
|
// CHECK: [[P:%.*]] = load i8*, i8**
|
2015-02-14 09:52:20 +08:00
|
|
|
// CHECK-NOT: icmp eq i8* [[P]], null
|
|
|
|
|
// CHECK-NOT: br i1
|
2011-07-13 14:10:41 +08:00
|
|
|
// CHECK: [[BEGIN:%.*]] = bitcast i8* [[P]] to [[A:%.*]]*
|
2015-02-28 03:18:17 +08:00
|
|
|
// CHECK-NEXT: [[END:%.*]] = getelementptr inbounds [[A]], [[A]]* [[BEGIN]], i64 5
|
2011-07-13 14:10:41 +08:00
|
|
|
// CHECK-NEXT: br label
|
|
|
|
|
// CHECK: [[CUR:%.*]] = phi [[A]]* [ [[BEGIN]], {{%.*}} ], [ [[NEXT:%.*]], {{%.*}} ]
|
2018-10-15 23:43:00 +08:00
|
|
|
// CHECK-NEXT: call void @_ZN6test151AC1Ev([[A]]* [[CUR]])
|
2015-02-28 03:18:17 +08:00
|
|
|
// CHECK-NEXT: [[NEXT]] = getelementptr inbounds [[A]], [[A]]* [[CUR]], i64 1
|
2011-07-13 14:10:41 +08:00
|
|
|
// CHECK-NEXT: [[DONE:%.*]] = icmp eq [[A]]* [[NEXT]], [[END]]
|
|
|
|
|
// CHECK-NEXT: br i1 [[DONE]]
|
2015-02-14 09:52:20 +08:00
|
|
|
void test1a(void *p) {
|
2011-05-16 09:05:12 +08:00
|
|
|
new (p) A[5];
|
|
|
|
|
}
|
|
|
|
|
|
2020-02-04 02:09:39 +08:00
|
|
|
// CHECK-LABEL: define void @_ZN6test156test1bEPv(
|
2015-02-28 05:19:58 +08:00
|
|
|
// CHECK: [[P0:%.*]] = load i8*, i8**
|
2015-02-14 09:52:20 +08:00
|
|
|
// CHECK: [[P:%.*]] = call i8* @_ZnamPvb(i64 13, i8* [[P0]]
|
|
|
|
|
// CHECK-NEXT: icmp eq i8* [[P]], null
|
|
|
|
|
// CHECK-NEXT: br i1
|
2015-02-28 03:18:17 +08:00
|
|
|
// CHECK: [[AFTER_COOKIE:%.*]] = getelementptr inbounds i8, i8* [[P]], i64 8
|
2015-02-14 09:52:20 +08:00
|
|
|
// CHECK: [[BEGIN:%.*]] = bitcast i8* [[AFTER_COOKIE]] to [[A:%.*]]*
|
2015-02-28 03:18:17 +08:00
|
|
|
// CHECK-NEXT: [[END:%.*]] = getelementptr inbounds [[A]], [[A]]* [[BEGIN]], i64 5
|
2015-02-14 09:52:20 +08:00
|
|
|
// CHECK-NEXT: br label
|
|
|
|
|
// CHECK: [[CUR:%.*]] = phi [[A]]* [ [[BEGIN]], {{%.*}} ], [ [[NEXT:%.*]], {{%.*}} ]
|
2018-10-15 23:43:00 +08:00
|
|
|
// CHECK-NEXT: call void @_ZN6test151AC1Ev([[A]]* [[CUR]])
|
2015-02-28 03:18:17 +08:00
|
|
|
// CHECK-NEXT: [[NEXT]] = getelementptr inbounds [[A]], [[A]]* [[CUR]], i64 1
|
2015-02-14 09:52:20 +08:00
|
|
|
// CHECK-NEXT: [[DONE:%.*]] = icmp eq [[A]]* [[NEXT]], [[END]]
|
|
|
|
|
// CHECK-NEXT: br i1 [[DONE]]
|
|
|
|
|
void test1b(void *p) {
|
|
|
|
|
new (p, true) A[5];
|
|
|
|
|
}
|
|
|
|
|
|
2011-05-16 09:05:12 +08:00
|
|
|
// TODO: it's okay if all these size calculations get dropped.
|
|
|
|
|
// FIXME: maybe we should try to throw on overflow?
|
2020-02-04 02:09:39 +08:00
|
|
|
// CHECK-LABEL: define void @_ZN6test155test2EPvi(
|
2015-02-28 05:19:58 +08:00
|
|
|
// CHECK: [[N:%.*]] = load i32, i32*
|
2011-05-16 09:05:12 +08:00
|
|
|
// CHECK-NEXT: [[T0:%.*]] = sext i32 [[N]] to i64
|
2015-02-28 05:19:58 +08:00
|
|
|
// CHECK-NEXT: [[P:%.*]] = load i8*, i8**
|
2011-07-13 14:10:41 +08:00
|
|
|
// CHECK: [[BEGIN:%.*]] = bitcast i8* [[P]] to [[A:%.*]]*
|
|
|
|
|
// CHECK-NEXT: [[ISEMPTY:%.*]] = icmp eq i64 [[T0]], 0
|
|
|
|
|
// CHECK-NEXT: br i1 [[ISEMPTY]],
|
2015-02-28 03:18:17 +08:00
|
|
|
// CHECK: [[END:%.*]] = getelementptr inbounds [[A]], [[A]]* [[BEGIN]], i64 [[T0]]
|
2011-07-13 14:10:41 +08:00
|
|
|
// CHECK-NEXT: br label
|
|
|
|
|
// CHECK: [[CUR:%.*]] = phi [[A]]* [ [[BEGIN]],
|
2018-10-15 23:43:00 +08:00
|
|
|
// CHECK-NEXT: call void @_ZN6test151AC1Ev([[A]]* [[CUR]])
|
2011-05-16 09:05:12 +08:00
|
|
|
void test2(void *p, int n) {
|
|
|
|
|
new (p) A[n];
|
|
|
|
|
}
|
|
|
|
|
}
|
2011-06-28 00:55:54 +08:00
|
|
|
|
|
|
|
|
namespace PR10197 {
|
2020-02-04 02:09:39 +08:00
|
|
|
// CHECK-LABEL: define weak_odr void @_ZN7PR101971fIiEEvv()
|
2011-06-28 00:55:54 +08:00
|
|
|
template<typename T>
|
|
|
|
|
void f() {
|
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
|
|
|
// CHECK: [[CALL:%.*]] = call noalias nonnull i8* @_Znwm
|
|
|
|
|
// CHECK-NEXT: [[CASTED:%.*]] = bitcast i8* [[CALL]] to
|
2011-06-28 00:55:54 +08:00
|
|
|
new T;
|
|
|
|
|
// CHECK-NEXT: ret void
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
template void f<int>();
|
|
|
|
|
}
|
2011-12-10 07:05:37 +08:00
|
|
|
|
|
|
|
|
namespace PR11523 {
|
|
|
|
|
class MyClass;
|
|
|
|
|
typedef int MyClass::* NewTy;
|
2020-02-04 02:09:39 +08:00
|
|
|
// CHECK-LABEL: define i64* @_ZN7PR115231fEv
|
2011-12-10 07:05:37 +08:00
|
|
|
// CHECK: store i64 -1
|
|
|
|
|
NewTy* f() { return new NewTy[2](); }
|
|
|
|
|
}
|
2012-02-17 06:45:48 +08:00
|
|
|
|
|
|
|
|
namespace PR11757 {
|
|
|
|
|
// Make sure we elide the copy construction.
|
|
|
|
|
struct X { X(); X(const X&); };
|
|
|
|
|
X* a(X* x) { return new X(X()); }
|
|
|
|
|
// CHECK: define {{.*}} @_ZN7PR117571aEPNS_1XE
|
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
|
|
|
// CHECK: [[CALL:%.*]] = call noalias nonnull i8* @_Znwm
|
2012-02-17 06:45:48 +08:00
|
|
|
// CHECK-NEXT: [[CASTED:%.*]] = bitcast i8* [[CALL]] to
|
2018-10-15 23:43:00 +08:00
|
|
|
// CHECK-NEXT: call void @_ZN7PR117571XC1Ev({{.*}}* [[CASTED]])
|
2012-02-17 06:45:48 +08:00
|
|
|
// CHECK-NEXT: ret {{.*}} [[CASTED]]
|
|
|
|
|
}
|
2012-08-25 15:11:29 +08:00
|
|
|
|
|
|
|
|
namespace PR13380 {
|
|
|
|
|
struct A { A() {} };
|
|
|
|
|
struct B : public A { int x; };
|
2020-02-04 02:09:39 +08:00
|
|
|
// CHECK-LABEL: define i8* @_ZN7PR133801fEv
|
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
|
|
|
// CHECK: call noalias nonnull i8* @_Znam(
|
2012-08-25 15:11:29 +08:00
|
|
|
// CHECK: call void @llvm.memset.p0i8
|
|
|
|
|
// CHECK-NEXT: call void @_ZN7PR133801BC1Ev
|
|
|
|
|
void* f() { return new B[2](); }
|
|
|
|
|
}
|
2013-07-22 07:12:18 +08:00
|
|
|
|
|
|
|
|
struct MyPlacementType {} mpt;
|
|
|
|
|
void *operator new(size_t, MyPlacementType);
|
|
|
|
|
|
|
|
|
|
namespace N3664 {
|
|
|
|
|
struct S { S() throw(int); };
|
|
|
|
|
|
2020-02-04 02:09:39 +08:00
|
|
|
// CHECK-LABEL: define void @_ZN5N36641fEv
|
2013-07-22 07:12:18 +08:00
|
|
|
void f() {
|
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
|
|
|
// CHECK: call noalias nonnull i8* @_Znwm(i64 4) [[ATTR_BUILTIN_NEW:#[^ ]*]]
|
2015-05-19 03:59:11 +08:00
|
|
|
int *p = new int; // expected-note {{allocated with 'new' here}}
|
2013-07-22 07:12:18 +08:00
|
|
|
// CHECK: call void @_ZdlPv({{.*}}) [[ATTR_BUILTIN_DELETE:#[^ ]*]]
|
|
|
|
|
delete p;
|
|
|
|
|
|
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
|
|
|
// CHECK: call noalias nonnull i8* @_Znam(i64 12) [[ATTR_BUILTIN_NEW]]
|
2013-07-22 07:12:18 +08:00
|
|
|
int *q = new int[3];
|
|
|
|
|
// CHECK: call void @_ZdaPv({{.*}}) [[ATTR_BUILTIN_DELETE]]
|
2015-05-19 03:59:11 +08:00
|
|
|
delete[] p; // expected-warning {{'delete[]' applied to a pointer that was allocated with 'new'; did you mean 'delete'?}}
|
2013-07-22 07:12:18 +08:00
|
|
|
|
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
|
|
|
// CHECK: call noalias i8* @_ZnamRKSt9nothrow_t(i64 3, {{.*}}) [[ATTR_BUILTIN_NOTHROW_NEW:#[^ ]*]]
|
2013-07-22 07:12:18 +08:00
|
|
|
(void) new (nothrow) S[3];
|
|
|
|
|
|
|
|
|
|
// CHECK: call i8* @_Znwm15MyPlacementType(i64 4){{$}}
|
|
|
|
|
(void) new (mpt) int;
|
|
|
|
|
}
|
|
|
|
|
|
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
|
|
|
// CHECK: declare i8* @_ZnamRKSt9nothrow_t(i64, {{.*}}) [[ATTR_NOBUILTIN_NOUNWIND_ALLOCSIZE:#[^ ]*]]
|
2013-07-22 07:12:18 +08:00
|
|
|
|
2020-02-04 02:09:39 +08:00
|
|
|
// CHECK-LABEL: define void @_ZN5N36641gEv
|
2013-07-22 07:12:18 +08:00
|
|
|
void g() {
|
|
|
|
|
// It's OK for there to be attributes here, so long as we don't have a
|
|
|
|
|
// 'builtin' attribute.
|
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
|
|
|
// CHECK: call noalias nonnull i8* @_Znwm(i64 4) {{#[^ ]*}}{{$}}
|
2013-07-22 07:12:18 +08:00
|
|
|
int *p = (int*)operator new(4);
|
|
|
|
|
// CHECK: call void @_ZdlPv({{.*}}) [[ATTR_NOUNWIND:#[^ ]*]]
|
|
|
|
|
operator delete(p);
|
|
|
|
|
|
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
|
|
|
// CHECK: call noalias nonnull i8* @_Znam(i64 12) {{#[^ ]*}}{{$}}
|
2013-07-22 07:12:18 +08:00
|
|
|
int *q = (int*)operator new[](12);
|
|
|
|
|
// CHECK: call void @_ZdaPv({{.*}}) [[ATTR_NOUNWIND]]
|
|
|
|
|
operator delete [](p);
|
|
|
|
|
|
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
|
|
|
// CHECK: call noalias i8* @_ZnamRKSt9nothrow_t(i64 3, {{.*}}) [[ATTR_NOUNWIND_ALLOCSIZE:#[^ ]*]]
|
2013-07-22 07:12:18 +08:00
|
|
|
(void) operator new[](3, nothrow);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2014-06-04 07:27:44 +08:00
|
|
|
namespace builtins {
|
2020-02-04 02:09:39 +08:00
|
|
|
// CHECK-LABEL: define void @_ZN8builtins1fEv
|
2014-06-04 07:27:44 +08:00
|
|
|
void f() {
|
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
|
|
|
// CHECK: call noalias nonnull i8* @_Znwm(i64 4) [[ATTR_BUILTIN_NEW]]
|
2014-06-04 07:27:44 +08:00
|
|
|
// CHECK: call void @_ZdlPv({{.*}}) [[ATTR_BUILTIN_DELETE]]
|
|
|
|
|
__builtin_operator_delete(__builtin_operator_new(4));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
|
|
|
// CHECK-DAG: attributes [[ATTR_NOBUILTIN]] = {{[{].*}} nobuiltin allocsize(0) {{.*[}]}}
|
2013-07-22 07:12:18 +08:00
|
|
|
// CHECK-DAG: attributes [[ATTR_NOBUILTIN_NOUNWIND]] = {{[{].*}} nobuiltin nounwind {{.*[}]}}
|
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
|
|
|
// CHECK-DAG: attributes [[ATTR_NOBUILTIN_NOUNWIND_ALLOCSIZE]] = {{[{].*}} nobuiltin nounwind allocsize(0) {{.*[}]}}
|
2013-07-22 07:12:18 +08:00
|
|
|
|
2015-08-14 02:10:32 +08:00
|
|
|
// CHECK-DAG: attributes [[ATTR_BUILTIN_NEW]] = {{[{].*}} builtin {{.*[}]}}
|
|
|
|
|
// CHECK-DAG: attributes [[ATTR_BUILTIN_DELETE]] = {{[{].*}} builtin {{.*[}]}}
|
|
|
|
|
|
2015-08-14 08:16:05 +08:00
|
|
|
// The ([^b}|...) monstrosity is matching a character that's not the start of 'builtin'.
|
|
|
|
|
// Add more letters if this matches some other attribute.
|
|
|
|
|
// CHECK-DAG: attributes [[ATTR_NOUNWIND]] = {{([^b]|b[^u]|bu[^i]|bui[^l])*}} nounwind {{([^b]|b[^u]|bu[^i]|bui[^l])*$}}
|
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
|
|
|
// CHECK-DAG: attributes [[ATTR_NOUNWIND_ALLOCSIZE]] = {{([^b]|b[^u]|bu[^i]|bui[^l])*}} nounwind allocsize(0) {{([^b]|b[^u]|bu[^i]|bui[^l])*$}}
|