[llvm-dev] RFC: ConstantPtrAuth for signed pointers on AArch64

Tim Northover via llvm-dev llvm-dev at lists.llvm.org
Wed Dec 9 01:47:33 PST 2020


On Tue, 8 Dec 2020 at 20:36, Peter Collingbourne <peter at pcc.me.uk> wrote:
> Could we make the discriminator a 64-bit field? For non-address-discriminated pointers it is possible to materialize the discriminator in a single instruction with almost 19 bits of entropy by making use of bit 30 (i.e. the selection between MOVN and MOVZ) and the HW bits. And I suppose that multi-instruction materialization of the discriminator is also possible (although it may not be practical to fit all of the bits into common object formats).

That hadn't occurred to me (the current implementation only allows low
16-bits), but it seems like a pretty good reason to expand the field.
I'll make the changes.

Not directly related to this patch but I think I'd favour an error
rather than multi-instruction materialization for "bad"
discriminators, at least to begin with.

> I mildly prefer keeping it as a Constant and not a ConstantExpr if we don't realistically expect this to be converted between constant and non-constant operands. That's similar to what we did for DSOLocalEquivalent for example. But I think I'd be fine either way.

Not that many places do, but in principle this definitely can be
converted in a way I don't think dso_local_equivalent can if I'm
reading the LangRef right. It's got a well-defined expansion in terms
of ptrauth intrinsics and syntactically it's indistinguishable from a
constant expression (unlike both dso_local_equivalent and blockaddress
which includes a normally non-constant basic-block component).

I was pretty disappointed that it didn't fit originally and quite like
Chris's suggestion to sink getAsInstruction as an alternative.

> It seems like it should be wider than i2 at least. There is also the GA key which I suppose it's conceivable that someone may want to use. And making it an i32 would easily allow future expansion, e.g. if more keys are added in the future, without requiring a bitcode upgrade path.

Ah yes, I'd forgotten about GA (we don't really use it right now as
far as I know).

Tim.


More information about the llvm-dev mailing list