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

[John McCall]

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.

>> If someone
>> comes to us and says, look, we really do have a platform like this,
>> and we're going to maintain an LLVM backend for it, and we'd like to
>> have clang as a frontend?  Then that's great, and we should do it
>> properly.  But I see no merit in complicating our implementation just
>> so that sizeof works properly when doing static analysis on a
>> platform that the project in general has no intention of supporting.
>> 
>> John.
> 
> So, under your point of view, clang is *only* the LLVM frontend.

*Only*? Of course not.  But it is *centered* around its existence as an LLVM frontend, and I think adding complexity to support a target we have no intention of ever generating IR for is not a good idea.  LLVM has occasionally removed support for unmaintained targets;  we would like to be able to do the same in clang, but we can't if merely parsing the code for a target is considered an abstract good that we cannot possibly regress on.

John.