[cfe-dev] The size of a pointer to function.

John McCall rjmccall at apple.com
Tue Feb 12 15:16:49 PST 2013

On Feb 12, 2013, at 1:28 PM, Abramo Bagnara <abramo.bagnara at bugseng.com> wrote:
> Il 12/02/2013 20:38, Abramo Bagnara ha scritto:
>> Il 12/02/2013 20:04, John McCall ha scritto:
>>> On Feb 12, 2013, at 7:01 AM, Enea Zaffanella <zaffanella at cs.unipr.it> wrote:
>>>> On 02/12/2013 01:55 AM, John McCall wrote:
>>>>> On Feb 8, 2013, at 1:08 AM, Enea Zaffanella <zaffanella at cs.unipr.it> wrote:
>>>>>> On 02/07/2013 09:30 PM, Tim Northover wrote:
>>>>>>>> Hence, the question is the following: are you willing to accept a
>>>>>>>> (hopefully) much less invasive patch that *only* ensures the correctness of
>>>>>>>> the AST info produced by clang for these (strange and otherwise unsupported,
>>>>>>>> but anyway standard compliant) targets?
>>>>>>> Even the AST produced can depend rather strongly on the target.
>>>>>>> Through obvious things like preprocessor magic, but also through more
>>>>>>> subtle issues like overload resolution.
>>>>>>> Are you imagining some kind of "target" with full driver support in
>>>>>>> Clang but no attempt at CodeGen? Otherwise it's not clear how this
>>>>>>> scheme could work.
>>>>>>> Tim.
>>>>>> I am not sure I have fully understood your question.
>>>>>> As a *library*, clang allows for your own tool to define your own
>>>>>> specific target deriving from TargetInfo (or one of its subclasses)
>>>>>> and set the appropriate values for its many features, among which
>>>>>> we have the size and alignment of pointer types. What we ask for is
>>>>>> only a separation between the two kinds of (object vs function)
>>>>>> pointers. (Side note: clang already supports differently sized
>>>>>> (object only) pointers via address spaces; to this end, TargetInfo
>>>>>> includes a few virtual functions that can be overridden; we are
>>>>>> already using this possibility).
>>>>>> For our own purposes, the thing above will be enough (in other
>>>>>> words, we have our own "driver" that sets up the target info
>>>>>> according to our needs). If deemed appropriate by clang developers,
>>>>>> we can add options controlling these target values in the clang
>>>>>> driver too. However, this would sound a bit contradictory: having a
>>>>>> full-blown driver option may (wrongly) suggest that full support is
>>>>>> provided by the whole frontend, including code generation. If this
>>>>>> (as hinted by John) is not currently among the priorities ...
>>>>> It doesn't make sense for this to be a driver option independent of
>>>>> the target triple.
>>>>> My objection is that this abstraction has real costs, and you seem to
>>>>> be interested in doing it purely theoretically, simply because the
>>>>> standard conceives of platforms that do so.
>>>> I have already explained that this is not "pure theory".
>>>> We do use our tools on targets having these features (that is, allowing for code & data placement in memory spaces having various pointer size requirements). As a matter of fact, these are not "alien" features: they are even available in the CPUX extension of the MSP430 target, which is one of the targets supported by clang/LLVM.
>>> If you can get LLVM's MSP430 maintainers on the record as planning to support this extension, then I'm willing to take your patch.
>> Who is MSP430 maintainer?


> I've just read in this page https://www.fooe.net/trac/llvm-msp430/ that
> indeed the people involved in llvm msp430 backend plan to add:
> - MSP430X support (specifically, near/far pointers)
> Is this what you wanted to accept this patch?

That page hasn't been touched since a small flurry of activity three years ago.
That is not an actual plan;  that is some people getting briefly excited by a
project and then abandoning it, which (to be frank) is an excellent summation
of the history of LLVM's MSP430 support.

Please just maintain your patch privately.


More information about the cfe-dev mailing list