On 11/27/23 13:03, Richard Sandiford wrote:
Joern Rennecke <joern.renne...@embecosm.com> writes:
On 11/20/23 11:26, Richard Sandiford wrote:
+ /* ?!? What is the point of this adjustment to DST_MASK? */
+ if (code == PLUS || code == MINUS
+ || code == MULT || code == ASHIFT)
+ dst_mask
+ = dst_mask ? ((2ULL << floor_log2 (dst_mask)) - 1) : 0;
Yeah, sympathise with the ?!? here :)
Jeff Law:
Inherited. Like the other bit of magic I think I'll do a test with them
pulled out to see if I can make something undesirable trigger.
This represents the carry effect. Even if the destination only cares about
some high order bits, you have to consider all lower order bits of the inputs.
For ASHIFT, you could refine this in the case of a constant shift count.
Ah, right. Think it would be worth a comment.
Definitely. Wouldn't SIGN_EXTEND have a similar problem? While we
don't care about all the low bits, we do care about that MSB.
But I wonder whether we should centralise all this code-specific
information into a single place. I.e. rather than having one switch to
say "PLUS is OK" or "AND is OK", and then having code-specific handling
elsewhere, we could enumerate how to handle a code.
Yea. That's where I was starting to go with the code which indicates we
can't necessarily narrow a shift count. ie, what are the properties of
the opcodes and how do they translate into the bits we need clear from
LIVENOW (for sets) and the bits we need to make live (for uses).
Jeff
