fix #52531, fix the effects modeling of QuoteNode

[aviatesk]

What observed in #52531 is that QuoteNode can embed global variables that users can modify. Therefore, when dealing with QuoteNode, it's necessary to taint its :inaccessiblememonly just like we do for GlobalRef.

• fixes Mutable let block variable treated as immutable in Julia 1.10 #52531
• replaces Be more conservative on memory effects when args are mutable #52536

[vchuravy]

I think in the current design this is the right solution.

Coming from LLVM our modelling of inaccessiblememonly is a bit odd. In LLVM inaccessiblememonly/argmemonly are properties of functions (declaration and calls) and are with respect to their arguments.

So Expr(:call, :getfield, obj, :x) could never be inaccesssiblememonly since it always access memory through it's argument.

It took me a while to understand that in Julia these are like the other effects modeled with respect to the containing/parent function.

E.g. inaccessiblememonly -> consistent (logical implies/conditional) If the parent function is proven to be inaccessiblememonly then getfield is consistent.
It may make sense to separate the memory effects out from other effects and handle them separate for #36832 I eventually need to ask the question: "What are the memory effects of this instruction" and there I need inaccessiblememonly and argmemonly in the LLVM sense. I would need to be able to answer the query: What memory semantics does this call have (not what memory semantics does this call imply for its parent). That's also why ModRef separates between write/read and then different scopes: global/task/arguments/inaccessible.

To infer the function global effects we would then need to ask the question "where did the memory come from".

[aviatesk]

Although I'm not completely certain about the exact interpretation of :inaccessiblememonly in the LLVM sense, it seems feasible to convert our representation to match LLVM's? For instance, a getfield call would be considered inaccessible in LLVM if :inaccessiblememonly = ALWAYS_TRUE, global if ALWAYS_FALSE, and argument if INACCESSIBLEMEM_OR_ARGMEMONLY (or am I missing your point?). Julia's :inaccessiblememonly doesn't currently cover read/write or task, but adding these features shouldn't be too challenging.

So Expr(:call, :getfield, obj, :x) could never be inaccesssiblememonly since it always access memory through it's argument.

Hmm really? As far as I understand LLVM's :inaccessiblememonly is all about mutable memory and that it's interpreted as :inaccessiblememonly when arguments are mutation-free, which is what we do on Julia-level analysis for getfield call.

[vchuravy]

(or am I missing your point?

I think so. My point is that in LLVM the memory attribute is with reference to the called function (not within the context of the calling function).

As far as I understand LLVM's :inaccessiblememonly is all about mutable memory

No. LLVM doesn't make the distinction between mutable/immutable memory that we do. So there is no refinement for immutable memory (which also wouldn't be inaccessiblememonly, but rather would be readnone)

InaccessibleMemOnly: This attribute indicates that the function may only access memory that is not accessible by the program/IR being compiled. This is a weaker form of ReadNone.

So it says this function does read memory, but none that is reachable from the caller (also see https://groups.google.com/g/llvm-dev/c/1ptivB6H6_c/m/oxLBU4tqAAAJ)

[gbaraldi]

Right, memory attributes with respect to arguments don't translate to the parent (they do for accessing globals of course).

[KristofferC]

@aviatesk, can you push a backported commit of this to the backport 1.10 branch?

[aviatesk]

@aviatesk, can you push a backported commit of this to the backport 1.10 branch?

Done.