RE: [MI400] optimizing MI code

["Paul Godtland" <plg@xxxxxxxxxx>]

Steve Richter asked:

|Does that mean the results can be retained in the registers of the cpu ?

Yes, that's a good example of an optimization that can be performed when
values do not have to be put into the storage specified on the MI
instruction.

| So exceptions are only handled on scope boundaries ?  Is that where
lumpiness comes in ?

The example of returning from an exception handler to the next MI
instruction, and the potential control flows that capability introduces,
was just meant to point out the optimization impacts. For example, assume
some MI instruction requires loading 3 pointers to address its operands.
The first load may fail (due to a problem with the pointer), so any
subsequent pointer loads done by that instruction can't be counted on to
have actually occurred when the code for the next MI instruction is
executed. Thus those subsequent pointer loads, if also needed for the next
MI instruction, must be redone there. Those addresses can't just be kept in
a register.

I think Jon talked about lumpiness. I don't know exactly what he means by
that and so won't try to speak for him.

| Is that correct ?  And if so, are pointer based variables not optimizable
?

The pointer addressability might be optimized beyond one MI instruction (if
it's not a pointer whose load might be bypassed due to an exception, as
mentioned above). The variable value itself almost certainly will not be.
RTNEXCP allows control to resume at the next MI instruction or a retry of
the MI instruction that took the exception. The retry capability means that
any data values anticipated by the instruction would have to be reset to
values they had before the code for the MI instruction executed. However,
while MI has automatic storage that's scoped to an invocation, it has no
storage class that's scoped to a single MI instruction. So, it's very hard
to optimize data values and allow RTNEXCP to always work properly.

As we've been discussing, RTNEXCP has a big impact on the ability to
optimize original MI. There are also other reasons why MI is not a good
language for optimization. The MI enhancements used to support languages
that generate W-Code don't have such inhibitors, so the very many classic
compiler optimizations, like common subexpression elimination, can be
readily performed.

Paul Godtland