simplify and fix blasDiffUse

[ZuseZ4]

Apparently you can introduce subtle bugs if you re-do work unnecessarily.
@wsmoses this new behavior should be always correct, right?

   27   if (val == arg_lda && need_lda && !cache_lda)
   26      return true;

At least it will fix the lda issue for runtime-activity. Adding some more tests there rn.

[wsmoses]

I think the cache part shouldn't be here since diffuse analysis is used by the algorithm to determine caching.

[ZuseZ4]

cacheMode just checks if it's forwardModeonly.
cache_ is also manually estimated, based on uses only:

   30   auto pos_lda = 7 + offset ;
   29   auto arg_lda = CI->getArgOperand(pos_lda);
   28   const bool overwritten_lda = (cacheMode ? (overwritten_args_ptr ? (*overwritten_args_ptr)[pos_lda] : true ) : false);

...
    2   bool cache_alpha = cacheMode && byRef && overwritten_alpha && need_alpha;
    3   bool need_lda = active_A || active_B || active_alpha
    4   bool cache_lda = cacheMode && byRef && overwritten_lda && need_lda;

So it's only the name, or am I using any information that I should not?
I do get the need_ conditions based on my usedBy Map: auto users = argUsers.lookup(argPos);,,
which I generate by parsing the .td declarations. So there shouldn't be a circular dependency.
I also use it inside of the blasTG to determine if I will either manually cache a variable or just lookup later,
so I guess it makes sense to use the same logic here?

[wsmoses]

Like mentioned on slack, I don't think it's right to do cache checks here since this analysis is used by cache analysis.

Can you revert the cache change?

[wsmoses]

Ah sorry I meant on here, not slack.

But yeah I believe there's an effective circular dependency, which here will be manifested by inconsistent results (not a compile time error), which is potentially very bad.

[ZuseZ4]

just to clarify @wsmoses. If it existend then it existed just on the same level before this PR. I did use exactly the same logic before this change, I just re-did some of the calculation instead of reusing the variables like I did now. If you want this to be fundamentally changed reverting will not change it, we would rather need to see what else tk use