llvm dev - May 2008 - [LLVMdev] 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.

 
>> Either way, I think we all agree that the root of the problem is the 
>> FIXME in SelectionDAGLowering::visitRet()
 
>What I would like to know is if the promotion of return values to
integer is specified by the C language standard, or if it is specified
by the (target specific) ABI.
> 
>Ciao,
> 
>Duncan.
 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080515/d1945587/attachment.html>

On Thu, 2008-05-15 at 09:48 -0700, Alireza.Moshtaghi at microchip.com
wrote:
> 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....
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

Am Donnerstag, den 15.05.2008, 13:58 -0400 schrieb Jonathan S.
Shapiro:
> So far, all of the use cases that I have seen exist because of
> architecture or OS compatibility constraints rather than language
> constraints.
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