Troubling promotion of return value to Integer ...

I know that many ABIs require this for performance purpose, but I haven’t seen anything in the standard that suggests promotion of return value to integer. Furthermore, I think the LLVM is supposed to be independent of language. So I’m not sure if SelectionDAGLowering is the right place for this promotion to begin with, TargetLowering class seems more logical; but I’m not sure how.

I can answer the ABI vs. language part of this question.

On modern systems, the definition of the standard calling convention is
part of the ABI so that procedure calls can be made compatibly across
language boundaries. Procedure return values are something that all
compilers on a given platform want very much to agree about. So your
particular case is not a language issue; it is a calling convention and
ABI issue.

I have seen examples (elsewhere) of languages that extended or modified
the calling convention in some way for a language-specific purpose. In
every case that I have personally used, this became a real problem at
some point for cross-language calling compatibility. The VAX PL/1 vs. C
calling convention discrepancies are probably the best known and most
cheerfully hated historical example of this.

LLVM does provide a mechanism to specify alternate calling conventions.
So far, all of the use cases that I have seen exist because of
architecture or OS compatibility constraints rather than language
constraints. Introducing a language-dependent convention has the
potential to add multiplicative complexity, because each language
convention needs to be mapped onto each target convention. This seems
like a really good thing to avoid if you are able to do so.

I don't think this answers your question about SelectionDagLowering vs.
TargetLowering. Hopefully somebody else can respond to that part.

shap

Historically, the OS APIs were written using a specific language (mostly
C nowadays).

So from a lineage perspective, these constraints are language
constraints, from a "why do I need this?" perspective, they are OS
constraints.
This might be the reason why people have different ideas about what kind
of constraint it is (language or OS).

(Architectural constraints are indeed language-independent.)

Regards,
Jo