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

[John McCall]

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?

Anton.

> 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.

John.