Nope, cost computation cannot be unified. For calls, list nodes are attributed extra costs to account for memory stores (PUSH on x86 and MOV/STR on other architectures). Other cases:

FIELD_LIST - This is technically part of the call node that uses it so probably it should have 0 cost with the call's own LIST node accounting for the memory store cost.
SIMD InitN arg list - These resemble calls, a list node can be considered as generating an "insert" instruction.
HWIntrinsic arg list - A few are like SIMD. In all other cases list nodes should have cost 0, they exists only to allow nodes with 3-5 operands.
PHI arg list - Everything PHI related should have cost 0, it's not real code.

"level" computation is also different. For calls, if you ignore complications such a register arguments, the number of required registers is max(arg1regs, arg2regs...) because once evaluated the argument value is stored to memory, it not longer needs a register. Other cases:

FIELD_LIST - Should probably be computed as part of the call.
SIMD InitN - Like call but requires an extra reg to build the result into.
HWIntrinsic - Some are like SIMD. The rest, not sure. Sethi-Ullman applies to binary nodes, for n-ary nodes you probably need to add n - 1 registers instead of just one.
PHI - These should be ignored, the number of registers is not relevant.

But GT_LIST nodes are terrible, I hope to get rid of them. Then list owning nodes should each compute whatever they need.

While I'm at it I'll note that there are some weird things going on in gtSetListOrder:

The use of a stack to reverse the list node order - this probably applies only to calls, not to other list users such as PHI and SIMD/HWIntinsic.
Checking for GTF_REVERSE_OPS on list nodes - there's no such thing, nobody is setting this flag on list nodes.

Unify cost computation for GT_LIST nodes #6622

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions