[clang] Allow inlining of copies without capabilities #506

arichardson · 2021-01-25T17:37:27Z

This pull request allows inlining of memcpy/memmove for structures/types
that are guaranteed to not contain tags if the size is >= cap_size.
The motivating case for this is that we currently call memcpy when
performing structure assignment for struct { long a; long b;} rather than
using two loads+stores.

The backends still conservatively assume that a copy may contain capabilities
if sizeof(void*), but at least we can now inline copies that are explicitly marked
as non-tag-preserving.
We do this by adding a new no_preserve_cheri_tags attribute. If
neither no_preserve_cheri_tags nor must_preserve_cheri_tags is set
we still fall back to the conservative behaviour of calling memcpy for
size>cap_size && align < cap_align.

Due to C's effective type rules, we have to be careful when setting the
attribute and only perform the type-base tag-preservation analysis if we
know the effective type. For example, marking a memcpy() to/from long*
as not tag-preserving could result in tag stripping for code that uses
type casts. Such code is correct even under strict aliasing rules since
the first store to a memory location determines the type. Example from
#506:

void *malloc(__SIZE_TYPE__);
void *memcpy(void *, const void *, __SIZE_TYPE__);

void foo(long **p, long **q) {
    *p = malloc(32);
    *q = malloc(32);
    (*p)[0] = 1;
    (*p)[1] = 2;
    *(void (**)(long **, long **))(*p + 2) = &foo;
    memcpy(*q, *p, 32);
}

Despite the memcpy() argument being a long* (and therefore intuitively
not tag preserving), we can't add the attribute since we don't actually
know the type of the underlying object (malloc creates an allocated with
no declared type). From C99:

The effective type of an object for an access to its stored value is the
declared type of the object, if any (footnote 75: Allocated objects have
no declared type).

If a value is stored into an object having no declared type through an
lvalue having a type that is not a character type, then the type of the
lvalue becomes the effective type of the object for that access and for
subsequent accesses that do not modify the stored value.

If a value is copied into an object having no declared type using memcpy
or memmove, or is copied as an array of character type, then the effective
type of the modified object for that access and for subsequent accesses
that do not modify the value is the effective type of the object from
which the value is copied, if it has one.

For all other accesses to an object having no declared type, the effective
type of the object is simply the type of the lvalue used for the access.

jrtc27

What happens with:

void *malloc(__SIZE_TYPE__);
void *memcpy(void *, const void *, __SIZE_TYPE__);

void foo(long **p, long **q) {
    *p = malloc(32);
    *q = malloc(32);
    (*p)[0] = 1;
    (*p)[1] = 2;
    *(void (**)(long **, long **))(*p + 2) = &foo;
    memcpy(*q, *p, 32);
}

I believe that's valid C, provided 2 * sizeof(long) is a multiple of void (**)(long **, long **).

clang/lib/CodeGen/CGBuiltin.cpp

clang/lib/CodeGen/CodeGenTypes.cpp

jrtc27 · 2021-01-25T21:54:38Z

What happens with:

void *malloc(__SIZE_TYPE__);
void *memcpy(void *, const void *, __SIZE_TYPE__);

void foo(long **p, long **q) {
    *p = malloc(32);
    *q = malloc(32);
    (*p)[0] = 1;
    (*p)[1] = 2;
    *(void (**)(long **, long **))(*p + 2) = &foo;
    memcpy(*q, *p, 32);
}

I believe that's valid C, provided 2 * sizeof(long) is a multiple of void (**)(long **, long **).

Imagine it as being that you have a pointer to a header and want to copy the header plus some amount of the body, where the body contains capabilities.

…iasing Marking a memcpy() to/from a long* as not tag-preserving could result in tag stripping for code that assumes relaxed aliasing. Example from CTSRD-CHERI#506: ``` void *malloc(__SIZE_TYPE__); void *memcpy(void *, const void *, __SIZE_TYPE__); void foo(long **p, long **q) { *p = malloc(32); *q = malloc(32); (*p)[0] = 1; (*p)[1] = 2; *(void (**)(long **, long **))(*p + 2) = &foo; memcpy(*q, *p, 32); } ``` Adding the no_preserve_tags attribute to memcpy() is safe under -fstrict-aliasing (since the store above is invalid), but with -fno-strict-aliasing this aligned memcpy must preserve tags.

arichardson · 2021-03-10T21:39:18Z

void (**)(long **, long **)

I believe storing a void (*)(long **, long **) to a variable of type long * is a strict aliasing violation, so in the new version of this PR I've made the optimization conditional on -f(no-)strict-aliasing. Struct assignment is always optimized though.

…type Marking a memcpy() to/from a long* as not tag-preserving could result in tag stripping for code that using type casts and is correct under strict aliasing rules since the first store to a memory location determines the type. Example from CTSRD-CHERI#506: ``` void *malloc(__SIZE_TYPE__); void *memcpy(void *, const void *, __SIZE_TYPE__); void foo(long **p, long **q) { *p = malloc(32); *q = malloc(32); (*p)[0] = 1; (*p)[1] = 2; *(void (**)(long **, long **))(*p + 2) = &foo; memcpy(*q, *p, 32); } ``` Despite the memcpy being a long* (and therefore intuitevly not tag preserving), we can't add the attribute since we don't actually know the type of the underlying object (malloc creates an allocated with no declared type). From C99: The effective type of an object for an access to its stored value is the declared type of the object, if any (footnote 75: Allocated objects have no declared type). If a value is stored into an object having no declared type through an lvalue having a type that is not a character type, then the type of the lvalue becomes the effective type of the object for that access and for subsequent accesses that do not modify the stored value. If a value is copied into an object having no declared type using memcpy or memmove, or is copied as an array of character type, then the effective type of the modified object for that access and for subsequent accesses that do not modify the value is the effective type of the object from which the value is copied, if it has one. For all other accesses to an object having no declared type, the effective type of the object is simply the type of the lvalue used for the access.

arichardson · 2021-03-12T15:12:10Z

As discussed earlier this week, my -fstrict-aliasing/-fno-strict-aliasing assumptions were incorrect, so this new version makes decisions based on whether a valid variable declaration is visible and if not assumes it is an "allocated type" where the first store defines the underlying type.

…type Marking a memcpy() to/from a long* as not tag-preserving could result in tag stripping for code that using type casts and is correct under strict aliasing rules since the first store to a memory location determines the type. Example from CTSRD-CHERI#506: ``` void *malloc(__SIZE_TYPE__); void *memcpy(void *, const void *, __SIZE_TYPE__); void foo(long **p, long **q) { *p = malloc(32); *q = malloc(32); (*p)[0] = 1; (*p)[1] = 2; *(void (**)(long **, long **))(*p + 2) = &foo; memcpy(*q, *p, 32); } ``` Despite the memcpy being a long* (and therefore intuitevly not tag preserving), we can't add the attribute since we don't actually know the type of the underlying object (malloc creates an allocated with no declared type). From C99: The effective type of an object for an access to its stored value is the declared type of the object, if any (footnote 75: Allocated objects have no declared type). If a value is stored into an object having no declared type through an lvalue having a type that is not a character type, then the type of the lvalue becomes the effective type of the object for that access and for subsequent accesses that do not modify the stored value. If a value is copied into an object having no declared type using memcpy or memmove, or is copied as an array of character type, then the effective type of the modified object for that access and for subsequent accesses that do not modify the value is the effective type of the object from which the value is copied, if it has one. For all other accesses to an object having no declared type, the effective type of the object is simply the type of the lvalue used for the access.

arichardson · 2021-07-15T16:31:51Z

rebased

…type Marking a memcpy() to/from a long* as not tag-preserving could result in tag stripping for code that using type casts and is correct under strict aliasing rules since the first store to a memory location determines the type. Example from CTSRD-CHERI#506: ``` void *malloc(__SIZE_TYPE__); void *memcpy(void *, const void *, __SIZE_TYPE__); void foo(long **p, long **q) { *p = malloc(32); *q = malloc(32); (*p)[0] = 1; (*p)[1] = 2; *(void (**)(long **, long **))(*p + 2) = &foo; memcpy(*q, *p, 32); } ``` Despite the memcpy being a long* (and therefore intuitevly not tag preserving), we can't add the attribute since we don't actually know the type of the underlying object (malloc creates an allocated with no declared type). From C99: The effective type of an object for an access to its stored value is the declared type of the object, if any (footnote 75: Allocated objects have no declared type). If a value is stored into an object having no declared type through an lvalue having a type that is not a character type, then the type of the lvalue becomes the effective type of the object for that access and for subsequent accesses that do not modify the stored value. If a value is copied into an object having no declared type using memcpy or memmove, or is copied as an array of character type, then the effective type of the modified object for that access and for subsequent accesses that do not modify the value is the effective type of the object from which the value is copied, if it has one. For all other accesses to an object having no declared type, the effective type of the object is simply the type of the lvalue used for the access.

arichardson · 2021-08-17T12:41:08Z

rebased

…type Marking a memcpy() to/from a long* as not tag-preserving could result in tag stripping for code that using type casts and is correct under strict aliasing rules since the first store to a memory location determines the type. Example from CTSRD-CHERI#506: ``` void *malloc(__SIZE_TYPE__); void *memcpy(void *, const void *, __SIZE_TYPE__); void foo(long **p, long **q) { *p = malloc(32); *q = malloc(32); (*p)[0] = 1; (*p)[1] = 2; *(void (**)(long **, long **))(*p + 2) = &foo; memcpy(*q, *p, 32); } ``` Despite the memcpy being a long* (and therefore intuitevly not tag preserving), we can't add the attribute since we don't actually know the type of the underlying object (malloc creates an allocated with no declared type). From C99: The effective type of an object for an access to its stored value is the declared type of the object, if any (footnote 75: Allocated objects have no declared type). If a value is stored into an object having no declared type through an lvalue having a type that is not a character type, then the type of the lvalue becomes the effective type of the object for that access and for subsequent accesses that do not modify the stored value. If a value is copied into an object having no declared type using memcpy or memmove, or is copied as an array of character type, then the effective type of the modified object for that access and for subsequent accesses that do not modify the value is the effective type of the object from which the value is copied, if it has one. For all other accesses to an object having no declared type, the effective type of the object is simply the type of the lvalue used for the access.

arichardson · 2021-10-04T19:33:07Z

rebased after upstream merge.

…type Marking a memcpy() to/from a long* as not tag-preserving could result in tag stripping for code that using type casts and is correct under strict aliasing rules since the first store to a memory location determines the type. Example from CTSRD-CHERI#506: ``` void *malloc(__SIZE_TYPE__); void *memcpy(void *, const void *, __SIZE_TYPE__); void foo(long **p, long **q) { *p = malloc(32); *q = malloc(32); (*p)[0] = 1; (*p)[1] = 2; *(void (**)(long **, long **))(*p + 2) = &foo; memcpy(*q, *p, 32); } ``` Despite the memcpy being a long* (and therefore intuitevly not tag preserving), we can't add the attribute since we don't actually know the type of the underlying object (malloc creates an allocated with no declared type). From C99: The effective type of an object for an access to its stored value is the declared type of the object, if any (footnote 75: Allocated objects have no declared type). If a value is stored into an object having no declared type through an lvalue having a type that is not a character type, then the type of the lvalue becomes the effective type of the object for that access and for subsequent accesses that do not modify the stored value. If a value is copied into an object having no declared type using memcpy or memmove, or is copied as an array of character type, then the effective type of the modified object for that access and for subsequent accesses that do not modify the value is the effective type of the object from which the value is copied, if it has one. For all other accesses to an object having no declared type, the effective type of the object is simply the type of the lvalue used for the access.

…type Marking a memcpy() to/from a long* as not tag-preserving could result in tag stripping for code that using type casts. Such code is correct even under strict aliasing rules since the first store to a memory location determines the type. Example from CTSRD-CHERI#506: ``` void *malloc(__SIZE_TYPE__); void *memcpy(void *, const void *, __SIZE_TYPE__); void foo(long **p, long **q) { *p = malloc(32); *q = malloc(32); (*p)[0] = 1; (*p)[1] = 2; *(void (**)(long **, long **))(*p + 2) = &foo; memcpy(*q, *p, 32); } ``` Despite the memcpy() being a long* (and therefore intuitively not tag preserving), we can't add the attribute since we don't actually know the type of the underlying object (malloc creates an allocated with no declared type). From C99: The effective type of an object for an access to its stored value is the declared type of the object, if any (footnote 75: Allocated objects have no declared type). If a value is stored into an object having no declared type through an lvalue having a type that is not a character type, then the type of the lvalue becomes the effective type of the object for that access and for subsequent accesses that do not modify the stored value. If a value is copied into an object having no declared type using memcpy or memmove, or is copied as an array of character type, then the effective type of the modified object for that access and for subsequent accesses that do not modify the value is the effective type of the object from which the value is copied, if it has one. For all other accesses to an object having no declared type, the effective type of the object is simply the type of the lvalue used for the access.

Once the backends handle the new attribute, this will allow inlining structure assignments for structs that are at least capability size but do not contain any capabilities (e.g. struct { long a; long b; }). We can also set the attribute for all trivial auto var-init cases since those patterns never contain valid capabilities. Due to C's effective type rules, we have to be careful when setting the attribute and only perform the type-base tag-preservation analysis if we know the effective type. For example, marking a memcpy() to/from `long*` as not tag-preserving could result in tag stripping for code that uses type casts. Such code is correct even under strict aliasing rules since the first store to a memory location determines the type. Example from CTSRD-CHERI#506: ``` void *malloc(__SIZE_TYPE__); void *memcpy(void *, const void *, __SIZE_TYPE__); void foo(long **p, long **q) { *p = malloc(32); *q = malloc(32); (*p)[0] = 1; (*p)[1] = 2; *(void (**)(long **, long **))(*p + 2) = &foo; memcpy(*q, *p, 32); } ``` Despite the memcpy() argument being a long* (and therefore intuitively not tag preserving), we can't add the attribute since we don't actually know the type of the underlying object (malloc creates an allocated with no declared type). From C99: ``` The effective type of an object for an access to its stored value is the declared type of the object, if any (footnote 75: Allocated objects have no declared type). If a value is stored into an object having no declared type through an lvalue having a type that is not a character type, then the type of the lvalue becomes the effective type of the object for that access and for subsequent accesses that do not modify the stored value. If a value is copied into an object having no declared type using memcpy or memmove, or is copied as an array of character type, then the effective type of the modified object for that access and for subsequent accesses that do not modify the value is the effective type of the object from which the value is copied, if it has one. For all other accesses to an object having no declared type, the effective type of the object is simply the type of the lvalue used for the access. ```

This allows inlining of structure assignments for structs that are at least capability size but do not contain any capabilities (e.g. `struct { long a; long b; }`). We can also set the attribute for all trivial auto var-init cases since those patterns never contain valid capabilities. Due to C's effective type rules, we have to be careful when setting the attribute and only perform the type-base tag-preservation analysis if we know the effective type. For example, marking a memcpy() to/from `long*` as not tag-preserving could result in tag stripping for code that uses type casts. Such code is correct even under strict aliasing rules since the first store to a memory location determines the type. Example from CTSRD-CHERI#506: ``` void *malloc(__SIZE_TYPE__); void *memcpy(void *, const void *, __SIZE_TYPE__); void foo(long **p, long **q) { *p = malloc(32); *q = malloc(32); (*p)[0] = 1; (*p)[1] = 2; *(void (**)(long **, long **))(*p + 2) = &foo; memcpy(*q, *p, 32); } ``` Despite the memcpy() argument being a long* (and therefore intuitively not tag preserving), we can't add the attribute since we don't actually know the type of the underlying object (malloc creates an allocated with no declared type). From C99: ``` The effective type of an object for an access to its stored value is the declared type of the object, if any (footnote 75: Allocated objects have no declared type). If a value is stored into an object having no declared type through an lvalue having a type that is not a character type, then the type of the lvalue becomes the effective type of the object for that access and for subsequent accesses that do not modify the stored value. If a value is copied into an object having no declared type using memcpy or memmove, or is copied as an array of character type, then the effective type of the modified object for that access and for subsequent accesses that do not modify the value is the effective type of the object from which the value is copied, if it has one. For all other accesses to an object having no declared type, the effective type of the object is simply the type of the lvalue used for the access. ```

clang/lib/CodeGen/CGBuilder.h

This allows inlining of structure assignments for structs that are at least capability size but do not contain any capabilities (e.g. `struct { long a; long b; }`). We can also set the attribute for all trivial auto var-init cases since those patterns never contain valid capabilities. Due to C's effective type rules, we have to be careful when setting the attribute and only perform the type-base tag-preservation analysis if we know the effective type. For example, marking a memcpy() to/from `long*` as not tag-preserving could result in tag stripping for code that uses type casts. Such code is correct even under strict aliasing rules since the first store to a memory location determines the type. Example from #506: ``` void *malloc(__SIZE_TYPE__); void *memcpy(void *, const void *, __SIZE_TYPE__); void foo(long **p, long **q) { *p = malloc(32); *q = malloc(32); (*p)[0] = 1; (*p)[1] = 2; *(void (**)(long **, long **))(*p + 2) = &foo; memcpy(*q, *p, 32); } ``` Despite the memcpy() argument being a long* (and therefore intuitively not tag preserving), we can't add the attribute since we don't actually know the type of the underlying object (malloc creates an allocated with no declared type). From C99: ``` The effective type of an object for an access to its stored value is the declared type of the object, if any (footnote 75: Allocated objects have no declared type). If a value is stored into an object having no declared type through an lvalue having a type that is not a character type, then the type of the lvalue becomes the effective type of the object for that access and for subsequent accesses that do not modify the stored value. If a value is copied into an object having no declared type using memcpy or memmove, or is copied as an array of character type, then the effective type of the modified object for that access and for subsequent accesses that do not modify the value is the effective type of the object from which the value is copied, if it has one. For all other accesses to an object having no declared type, the effective type of the object is simply the type of the lvalue used for the access. ```

This allows inlining of structure assignments for structs that are at least capability size but do not contain any capabilities (e.g. `struct { long a; long b; }`). We can also set the attribute for all trivial auto var-init cases since those patterns never contain valid capabilities. Due to C's effective type rules, we have to be careful when setting the attribute and only perform the type-base tag-preservation analysis if we know the effective type. For example, marking a memcpy() to/from `long*` as not tag-preserving could result in tag stripping for code that uses type casts. Such code is correct even under strict aliasing rules since the first store to a memory location determines the type. Example from CTSRD-CHERI#506: ``` void *malloc(__SIZE_TYPE__); void *memcpy(void *, const void *, __SIZE_TYPE__); void foo(long **p, long **q) { *p = malloc(32); *q = malloc(32); (*p)[0] = 1; (*p)[1] = 2; *(void (**)(long **, long **))(*p + 2) = &foo; memcpy(*q, *p, 32); } ``` Despite the memcpy() argument being a long* (and therefore intuitively not tag preserving), we can't add the attribute since we don't actually know the type of the underlying object (malloc creates an allocated with no declared type). From C99: ``` The effective type of an object for an access to its stored value is the declared type of the object, if any (footnote 75: Allocated objects have no declared type). If a value is stored into an object having no declared type through an lvalue having a type that is not a character type, then the type of the lvalue becomes the effective type of the object for that access and for subsequent accesses that do not modify the stored value. If a value is copied into an object having no declared type using memcpy or memmove, or is copied as an array of character type, then the effective type of the modified object for that access and for subsequent accesses that do not modify the value is the effective type of the object from which the value is copied, if it has one. For all other accesses to an object having no declared type, the effective type of the object is simply the type of the lvalue used for the access. ``` There is another important caveat: we have to conservatively assume that the copy affects adjacent data (e.g. C++ subclass fields) that could hold capabilities if we don't know the copy size. If the copy size is <= sizeof(T), we can mark copies as non-tag-preserving since it cannot affect trailing fields (even if we are actually copying a subclass).

These tests highlight some places where we can easily add the no_preserve_tags attribute to allow inlining small copies.

This allows inlining of structure assignments for structs that are at least capability size but do not contain any capabilities (e.g. `struct { long a; long b; }`). We can also set the attribute for all trivial auto var-init cases since those patterns never contain valid capabilities. Due to C's effective type rules, we have to be careful when setting the attribute and only perform the type-base tag-preservation analysis if we know the effective type. For example, marking a memcpy() to/from `long*` as not tag-preserving could result in tag stripping for code that uses type casts. Such code is correct even under strict aliasing rules since the first store to a memory location determines the type. Example from CTSRD-CHERI#506: ``` void *malloc(__SIZE_TYPE__); void *memcpy(void *, const void *, __SIZE_TYPE__); void foo(long **p, long **q) { *p = malloc(32); *q = malloc(32); (*p)[0] = 1; (*p)[1] = 2; *(void (**)(long **, long **))(*p + 2) = &foo; memcpy(*q, *p, 32); } ``` Despite the memcpy() argument being a long* (and therefore intuitively not tag preserving), we can't add the attribute since we don't actually know the type of the underlying object (malloc creates an allocated with no declared type). From C99: ``` The effective type of an object for an access to its stored value is the declared type of the object, if any (footnote 75: Allocated objects have no declared type). If a value is stored into an object having no declared type through an lvalue having a type that is not a character type, then the type of the lvalue becomes the effective type of the object for that access and for subsequent accesses that do not modify the stored value. If a value is copied into an object having no declared type using memcpy or memmove, or is copied as an array of character type, then the effective type of the modified object for that access and for subsequent accesses that do not modify the value is the effective type of the object from which the value is copied, if it has one. For all other accesses to an object having no declared type, the effective type of the object is simply the type of the lvalue used for the access. ``` There is another important caveat: we have to conservatively assume that the copy affects adjacent data (e.g. C++ subclass fields) that could hold capabilities if we don't know the copy size. If the copy size is <= sizeof(T), we can mark copies as non-tag-preserving since it cannot affect trailing fields (even if we are actually copying a subclass). We are also conservative if the structure contains an array of type ((un)signed) char or std::byte since those are often used to store arbitrary data (including capabilities). We could make this check more strict and require the array to be capability aligned, but that could be done as a follow-up change.

arichardson · 2022-10-05T14:01:30Z

I've dropped all the more complex logic from this patch - should be easier to review now.

arichardson · 2022-10-05T14:27:25Z

clang/lib/AST/ASTContext.cpp

+    if (Ty->isCHERICapabilityType(*this))
+      return false;
+    else if (const RecordType *RT = Ty->getAs<RecordType>()) {
+      if (!cannotContainCapabilities(RT->getDecl()))


The double negatives make this function implementation rather ugly, but I think it makes more sense for callers such as CodeGenTypes::copyShouldPreserveTagsForPointee().

This allows inlining of structure assignments for structs that are at least capability size but do not contain any capabilities (e.g. `struct { long a; long b; }`). We can also set the attribute for all trivial auto var-init cases since those patterns never contain valid capabilities. Due to C's effective type rules, we have to be careful when setting the attribute and only perform the type-base tag-preservation analysis if we know the effective type. For example, marking a memcpy() to/from `long*` as not tag-preserving could result in tag stripping for code that uses type casts. Such code is correct even under strict aliasing rules since the first store to a memory location determines the type. Example from #506: ``` void *malloc(__SIZE_TYPE__); void *memcpy(void *, const void *, __SIZE_TYPE__); void foo(long **p, long **q) { *p = malloc(32); *q = malloc(32); (*p)[0] = 1; (*p)[1] = 2; *(void (**)(long **, long **))(*p + 2) = &foo; memcpy(*q, *p, 32); } ``` Despite the memcpy() argument being a long* (and therefore intuitively not tag preserving), we can't add the attribute since we don't actually know the type of the underlying object (malloc creates an allocated with no declared type). From C99: ``` The effective type of an object for an access to its stored value is the declared type of the object, if any (footnote 75: Allocated objects have no declared type). If a value is stored into an object having no declared type through an lvalue having a type that is not a character type, then the type of the lvalue becomes the effective type of the object for that access and for subsequent accesses that do not modify the stored value. If a value is copied into an object having no declared type using memcpy or memmove, or is copied as an array of character type, then the effective type of the modified object for that access and for subsequent accesses that do not modify the value is the effective type of the object from which the value is copied, if it has one. For all other accesses to an object having no declared type, the effective type of the object is simply the type of the lvalue used for the access. ``` There is another important caveat: we have to conservatively assume that the copy affects adjacent data (e.g. C++ subclass fields) that could hold capabilities if we don't know the copy size. If the copy size is <= sizeof(T), we can mark copies as non-tag-preserving since it cannot affect trailing fields (even if we are actually copying a subclass). We are also conservative if the structure contains an array of type ((un)signed) char or std::byte since those are often used to store arbitrary data (including capabilities). We could make this check more strict and require the array to be capability aligned, but that could be done as a follow-up change.

arichardson requested a review from jrtc27 January 25, 2021 17:37

jrtc27 reviewed Jan 25, 2021

View reviewed changes

clang/lib/CodeGen/CGBuiltin.cpp Outdated Show resolved Hide resolved

clang/lib/CodeGen/CodeGenTypes.cpp Outdated Show resolved Hide resolved

brooksdavis mentioned this pull request Feb 15, 2021

Document when tags are preserved when copying memory CTSRD-CHERI/cheri-c-programming#12

Open

arichardson force-pushed the memcpy-no-tags branch from 035d46b to b4f4de8 Compare March 10, 2021 21:38

arichardson requested a review from jrtc27 March 10, 2021 21:39

arichardson force-pushed the memcpy-no-tags branch from b4f4de8 to e147562 Compare March 12, 2021 15:10

arichardson force-pushed the memcpy-no-tags branch from e147562 to 09e3f46 Compare July 15, 2021 16:30

arichardson force-pushed the memcpy-no-tags branch from 09e3f46 to bacd109 Compare August 17, 2021 12:41

arichardson force-pushed the memcpy-no-tags branch from bacd109 to 7e96616 Compare October 4, 2021 19:32

arichardson mentioned this pull request Oct 15, 2021

Introduce the no_preserve_tags_attribute #582

Closed

arichardson marked this pull request as draft October 21, 2021 13:26

arichardson force-pushed the no-preserve-tags-codegen branch from a24d4d2 to 89a3cd0 Compare May 14, 2022 22:27

arichardson force-pushed the no-preserve-tags-codegen branch 2 times, most recently from 0c5b087 to 2c713b3 Compare August 16, 2022 09:55

arichardson force-pushed the no-preserve-tags-codegen branch 2 times, most recently from 1539e37 to 66d47e7 Compare August 26, 2022 10:53

arichardson force-pushed the memcpy-no-tags branch from 4c201bc to 528ce37 Compare August 26, 2022 16:16

arichardson changed the title ~~Allow inlining of copies without capabilities~~ [clang] Allow inlining of copies without capabilities Aug 26, 2022

arichardson commented Aug 26, 2022

View reviewed changes

clang/lib/CodeGen/CGBuilder.h Outdated Show resolved Hide resolved

arichardson force-pushed the memcpy-no-tags branch from 528ce37 to 952b02c Compare September 1, 2022 14:54

arichardson force-pushed the memcpy-no-tags branch from 952b02c to d4dc697 Compare September 2, 2022 14:21

arichardson mentioned this pull request Oct 5, 2022

Catch invalid uses of {must,no}_preserve_cheri_tag #648

Open

arichardson force-pushed the no-preserve-tags-codegen branch from 66d47e7 to f8a0d53 Compare October 5, 2022 11:13

arichardson added 4 commits October 5, 2022 11:14

Add tests for clang setting the no_preserve_cheri_tags attribute

aa0e6c8

These tests highlight some places where we can easily add the no_preserve_tags attribute to allow inlining small copies.

Drop an unncessary legacy target triple from a test

3d6998a

Memory copies of less than cap size do not need to preserve tags

3712d60

arichardson force-pushed the memcpy-no-tags branch from d4dc697 to 3712d60 Compare October 5, 2022 14:00

arichardson requested a review from jrtc27 October 5, 2022 14:00

arichardson commented Oct 5, 2022

View reviewed changes

arichardson deleted the branch CTSRD-CHERI:no-preserve-tags-codegen October 6, 2022 12:56

arichardson closed this Oct 6, 2022

arichardson mentioned this pull request Oct 6, 2022

Set no_preserve_tags for copies of structs without capabilities #650

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[clang] Allow inlining of copies without capabilities #506

[clang] Allow inlining of copies without capabilities #506

arichardson commented Jan 25, 2021 •

edited

jrtc27 left a comment •

edited

jrtc27 commented Jan 25, 2021

arichardson commented Mar 10, 2021 •

edited

arichardson commented Mar 12, 2021

arichardson commented Jul 15, 2021

arichardson commented Aug 17, 2021

arichardson commented Oct 4, 2021

arichardson commented Oct 5, 2022

arichardson Oct 5, 2022

[clang] Allow inlining of copies without capabilities #506

[clang] Allow inlining of copies without capabilities #506

Conversation

arichardson commented Jan 25, 2021 • edited

jrtc27 left a comment • edited

Choose a reason for hiding this comment

jrtc27 commented Jan 25, 2021

arichardson commented Mar 10, 2021 • edited

arichardson commented Mar 12, 2021

arichardson commented Jul 15, 2021

arichardson commented Aug 17, 2021

arichardson commented Oct 4, 2021

arichardson commented Oct 5, 2022

arichardson Oct 5, 2022

Choose a reason for hiding this comment

arichardson commented Jan 25, 2021 •

edited

jrtc27 left a comment •

edited

arichardson commented Mar 10, 2021 •

edited