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

[Abramo Bagnara]

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?

-- 
Abramo Bagnara

BUGSENG srl - http://bugseng.com
mailto:abramo.bagnara at bugseng.com