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

[Enea Zaffanella]

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.

> To me, that does not
> seem like a good use of my time as a reviewer/maintainer.

This is an important consideration: be sure that we are not 
underestimating the value of your time.
If you want to have an idea, I am attaching the current draft of our 
patch, having the following characteristics:

  - memory size impact: a boolean flag added to TargetInfo and two new 
entries in its virtual table;

  - efficiency impact: the new boolean flag need to be tested when 
querying for the size of a pointer; if it is unset (which is the default 
for all currently supported targets), no other overhead is incurred;

  - maintenance impact: to minimize it, we factored out some common code 
in a new ASTContext utility method (just a few lines of code); this is 
the only place where we test the Boolean flag, as said above, and 
possibly call the new virtual functions (no virtual calls for currently 
supported targets).

> 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.
That's fine ... if it will not enter trunk, we will end up maintaining 
the patch out-of-tree. That's unfortunate, since in the end what we are 
proposing could be seen as a step in the right direction.

Regards,
Enea.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: FunctionPointerWidthAlign.patch
Type: text/x-diff
Size: 5918 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130212/0c2f895f/attachment.patch>