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. OTOH, if the output is not wider, then the high bit of the input is only life if the same bit of the output is. That latter point is important because chains of same-width sign extends are a prime target for this optimization. SMUL_HIGHPART / UMUL_HIGHPART also have carry-propagation. With the saturating operations, we also have propagations from high bit into lower bits in the saturating case. I don't think we can do anything useful for the saturating addition / multiplication operators safely. For the saturating truncation operations, we have the high-to-low propagation, but no low-to-high propagation, so that would be something separate to model.
