Intrinsic: idempotent

[kripken]

An idempotent function may do work when called, but if called again with
the same parameters, it does no work and it returns the same value (if it
returns a value).

This uses the new intrinsic in OptimizeInstructions. More things are
possible too.

See discussion in #7574

[kripken]

The refactoring in OptimizeInstructions had an additional benefit, it turns out. I moved that out to #8355

[kripken]

Btw, I noticed that C has something similar to this: [reproducible]. However that is "effectless and idempotent", and here we only want idempotency. There is a request for idempotency like ours on gcc but it wasn't added AFAICT. (cc @dschuff )

[tlively]

I don't think this is correct. An idempotent function could return new values on each call as long as it gets different parameters each time (for example if it's either creating new values or looking them up in a cache). It seems like this would cause problems for users of isShallowlyGenerative, at least.

[kripken]

I think that's already in the definition of generative?

binaryen/src/ir/properties.h

Lines 558 to 559 in 4efcdfe

	// A "generative" expression is one that can generate different results for the
	// same inputs, and that difference is *not* explained by other expressions that

If the inputs change, all bets are off.

Users of isShallowlyGenerative need to look at children, correct. LocalCSE does that, basically the "shallow" version is an incremental one, more efficient sometimes, but the children must be scanned as well.

[tlively]

I would also expect us to have to check that the child values match here. Do we not?

[kripken]

We check that the entire expressions match, including children, on line 2891.

It is just that it seems more efficient to do it in this order (the equality check scans both inputs, not just one, so early exit can avoid scanning half the data).

[tlively]

Yeah, I think this would be a nice cleanup anyway.

[kripken]

sg, will do it soon.

[tlively]

Or "alipotent" from the Latin root "Ali-" meaning "different" 😀

[tlively]

Let's add cases where just one or the other of the calls is marked idempotent. (Although what would the meaning of that be? Optimizable whenever the second call is marked idempotent, perhaps?)

[kripken]

Yes, when the second is marked, that seems right. Added.

[tlively]

Is this enough to write CSE tests that show idempotent function calls being deduplicated?

[kripken]

CSE needs to actually find the two calls, and only then can it infer that the second is removable. So this does require logic in each pass, like the areEqualAndFoldable part here. That and OnceReduction I can do later.