bpo-38328: Speed up the creation time of constant set literals.

[brandtbucher]

This is basically the same patch as #16498, except for sets. It's nearly identical, except that it adds a new argument to fold_tuple_on_constants to create a frozenset instead.

This one can probably be merged first, since the other PR is waiting for a list overallocation issue to be resolved.

https://bugs.python.org/issue38328

[brandtbucher]

@serhiy-storchaka, care to review (since you reviewed the other)?

[ZackerySpytz]

I'm pretty sure Py_SETREF() should be used here instead of this temporary variable.

[brandtbucher]

Is Py_SETREF(newconst, PyFrozenSet_New(newconst)) really clearer and safer? I can add it if you think so, but I personally don’t...

[methane]

I think it should be implemented in AST, not in peephole.

[brandtbucher]

@methane I don’t think that there’s any precedent for adding nodes in the AST optimizer; just changing or removing existing ones. This change (and the other one for lists, which has already been approved by @serhiy-storchaka) would essentially require making a new constant, nesting that inside of a new star unpacking node, and nesting that inside of the final container literal node.

The peephole optimizer already has the machinery for folding tuples, which can be trivially modified to work for lists and sets in this manner. Is there any reason you think it should be moved, other than the possibility of leaving unused constants in co_consts?

[methane]

I don’t think...

It may be done in the compiler instead of AST-optimizer.

Even though some code are leaved in peephole, we had moved most optimizer to AST.
For example, tuple creation expression (e.g. (1, 2, 3)) is folded in AST optimizer already.

Tuple folding is remaining in peephole only because some other AST nodes produce BUILD_TUPLE ops.

[brandtbucher]

Ah, I see. It looks like this can actually be done pretty easily in starunpack_helper. I'll have another PR up soon for comparison. Thanks @methane!