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

[Abramo Bagnara]

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?

-- 
Abramo Bagnara

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