[PATCH] D88385: [TableGen][M68K] (Patch 1/8) Utilities for complex instruction addressing modes: CodeBeads and logical operand helper functions

Sat Jan 2 17:36:15 PST 2021

myhsu added a comment.

In D88385#2476359 <https://reviews.llvm.org/D88385#2476359>, @Paul-C-Anagnostopoulos wrote:

> I was thinking of using a bit in the other flags member, Flags, as opposed to TSFlags. Then there would be nothing sneaky going on in the union itself.
>
> Making it an anonymous union would mean that all current references to TSFlags would still work, correct?

In D88385#2476330 <https://reviews.llvm.org/D88385#2476330>, @jrtc27 wrote:

> In D88385#2476329 <https://reviews.llvm.org/D88385#2476329>, @Paul-C-Anagnostopoulos wrote:
>
>> @jrtc27 Will some sort of union of a uint64_t and a pointer work? One of the Flags bits could specify which one it is.
>>
>> I agree that it would be cleaner to encode the information as flags, if possible.
>
> That'd work, yes, so long as you either have the flag bit being _zero_ mean it's a pointer or you put the flag bit sufficiently low down (preferably bit 0) as otherwise you'll take the pointer way outside the bounds of the corresponding allocation by setting a high bit; in order to fit the bounds and 64-bit address in 128 bits we compress the bounds and rely on pointers not going "too far" out of bounds (anything other than one-past-the-end is UB in C/C++, but we relax that somewhat for compatibility, roughly in proportion to the size of the allocation), but if they do then they're marked invalid and won't work later even though you mask the bit out.

Sounds like a plan, I will update this patch accordingly

Thanks for the brainstorming

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88385/new/

https://reviews.llvm.org/D88385