On 11/28/23 06:36, Joern Rennecke wrote:
On Mon, 27 Nov 2023 at 20:18, Jeff Law <j...@ventanamicro.com> wrote:
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.
Yes, if bits outside of the MODE_MASK of the input (i.e. higher bits) are
life in the output, than we want the high bit of the SIGN_EXTEND input live.
So I had a hack in my tree to do this for a while, but it was early in
the effort to test this across more targets. It wasn't clear at that
point in the effort if it was correct or just working around bugs
elsewhere. After we had everything working across the various targets I
pulled it out without ill effects. It looks like you're handling it in
your carry_backpropagate changes.
Jeff
