llvm dev - Apr 2012 - [LLVMdev] [llvm-commits] [cfe-commits] [Patch?] Fix handling of ARM homogenous aggregates

Tim,
> Opinions, anyone? (Hint hint).
I think here stuff should be thought of from different points. While
providing source type for argument might be beneficial, it might cause
moving the code from frontend to backend. Consider e.g. passing struct
by value including crazy padding inside. The ABI might specify that
padding should be removed and struct is passed field-by-field.

Also, note that in many cases the ABI rules are worded in terms of
source language which might now be preserved during IR generation,
so...

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hi all,

I think that ABI of LLVM IR level is different from ABI on real architecture
such as ARM or x86. ABI of LLVM IR level doesn't consider about register
usage. It just describes parameters and padding information related to
alignment of parameters. As Anton mentioned, LLVM have expressed ABI
information on bitcode using front-end. If someone wants to maintain information
from high level language like C or C++ on ABI of LLVM IR level, backend must
be modify. In order to change parameter information from high level language
to target specific information, I recommend to modify
llvm::TargetLowering::LowerCallTo().
You will be able to make padding information related to target.

Good luck,
Jin-Gu Kang
________________________________________
From: llvm-commits-bounces at cs.uiuc.edu [llvm-commits-bounces at cs.uiuc.edu]
On Behalf Of Anton Korobeynikov [anton at korobeynikov.info]
Sent: Friday, April 06, 2012 6:42 PM
To: Tim Northover
Cc: llvm-commits at cs.uiuc.edu; Hägglund H; James Molloy; Patrik at
dcs-maillist.cs.uiuc.edu; llvmdev at cs.uiuc.edu
Subject: Re: [llvm-commits] [cfe-commits] [LLVMdev] [Patch?] Fix handling of ARM
homogenous aggregates

Tim,
> Opinions, anyone? (Hint hint).
I think here stuff should be thought of from different points. While
providing source type for argument might be beneficial, it might cause
moving the code from frontend to backend. Consider e.g. passing struct
by value including crazy padding inside. The ABI might specify that
padding should be removed and struct is passed field-by-field.

Also, note that in many cases the ABI rules are worded in terms of
source language which might now be preserved during IR generation,
so...

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University
_______________________________________________
llvm-commits mailing list
llvm-commits at cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

> I think that ABI of LLVM IR level is different from ABI on real
architecture
> such as ARM or x86. ABI of LLVM IR level doesn't consider about
register
> usage. It just describes parameters and padding information related to
> alignment of parameters. 
I'm not sure what you mean here. LLVM's IR certainly doesn't care
about
registers and so on, but the LLVM backends have to, and front-ends have to 
know to a greater or lesser degree how the backends actually do it so that 
they can create ABI compliant code.

My view (possibly biased by the ARM ABI) is that LLVM's primary goal should
be
to make writing an ABI-compliant front-end as easy as possible. After that it 
should aim to have a sane ABI for hand-written LLVM code, and finally it 
should try to follow the ABI itself where possible (the last two are possibly 
interchangeable, but the first is primary).

The current situation with HFAs is that, without changes to make the backend 
aware of the concept, the front-end needs to know the entire sequence of 
previous arguments and how LLVM lowers them to work out how to pass an HFA 
correctly. 

The goal I'd like to see reached is that a front-end should be able to map
one
of its types to an LLVM type and know that if it uses that LLVM type then LLVM 
will do the right thing. As far as I'm aware, this is what happens for other
targets already (we *are* a bit weird with the HFAs). I think this is 
achievable for the ARM ABI too: LLVM's type system is certainly rich enough
to
capture the distinctions necessary. 
>From Anton:
> I think here stuff should be thought of from different points. While
> providing source type for argument might be beneficial, it might cause
> moving the code from frontend to backend. 
That could certainly go too far, but conceptually it's not necessarily a 
massive problem: if multiple front-ends implement the same ABI calling 
conventions, then perhaps the shared backend is the right place to put that 
common code.

And conversely, I think that if a front-end is worrying about the allocation 
of register numbers then something is a little awry.

But I suppose there will be a substantial cost to implementing this, wherever 
we put it.
> Consider e.g. passing struct
> by value including crazy padding inside. The ABI might specify that
> padding should be removed and struct is passed field-by-field.
To me that would still be a prime candidate for the front-end doing the work: 
it still seems to have an essentially context-free representation as a 
(sequence of) LLVM types.
> Also, note that in many cases the ABI rules are worded in terms of
> source language which might now be preserved during IR generation,
> so...
I'm not sure I follow this point. Is preserving the source language a bad 
thing for some reason I'm missing? Certainly, if it affects optimisation it 
would be.

Tim.