Implement __cheri_offset and __cheri_addr casts

[khilangudka]

These casts allow you to obtain the offset and address, and follow the same style of __cheri_ptr (renamed from __cheri_cast) whereby you write the type after the keyword:

long x = (__cheri_offset long)cap;

and

long y = (__cheri_addr long)cap;

They get turned into calls to the intrinsics llvm.cheri.cap.offset.get and llvm.cheri.cap.address.get respectively.

__cheri_cast is still supported but results in a deprecated warning.

[khilangudka]

Should __cheri_fromcap and __cheri_tocap be allowed in purecap ABI mode? Would they just become no-ops?

[davidchisnall]

Yes, because we can have a type declared with #pragma pointer_interpretation integer that we can cast to and from. They're probably not sensible to use, because such pointers probably come from another DDC and so the result may not be sensible, but if the user does an explicit cast then we don't guarantee sanity...

[arichardson]

I think in the purecap ABI the pointer interpretation pragma changes the type to long in the AST so I don't think it will work. However, we do need them to be available as noops so that we can compile code both as hybrid and as purecap.

[davidchisnall]

I don't really like having them be nops. You can #define them away in pure-cap mode if you know that's what you're doing, but having explicit casts that are silently ignored sounds like a good source of bugs.

[khilangudka]

In the purecap ABI, they would only be no-ops if the source and destination types are capabilities and the types are compatible.

[arichardson]

Yes, in the purecap mode they can either be no-ops or errors due to incompatible types. I think this is better than just #defining it away to turn it into a C-style cast that can change the type.

[davidchisnall]

In the hybrid ABI, what happens if the source and destination are both capabilities and the types are compatible? I really don't like this inconsistency - if you do an explicit cast and the destination type is the wrong kind of thing, then you're doing something wrong. It's trivial for someone to put:

#ifdef __CHERI_PURE_CAPABILITY__
#define __cheri_tocap
#define __cheri_fromcap
#endif

in a common header if they want this, but by making them silently nops we're letting the user write something that the compiler knows is wrong and silently accepting it. At the very least, this should be a warning.

[khilangudka]

I've currently implemented __cheri_fromcap and __cheri_tocap so that they would also be no-ops for hybrid code (provided that types are compatible). We are currently outputting a warning for hybrid code but we can output warnings for pure code as well.

[arichardson]

This has been merged