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

[Enea Zaffanella]

On 02/07/2013 07:45 PM, John McCall wrote:
> On Feb 7, 2013, at 10:14 AM, John McCall <rjmccall at apple.com> wrote:
>> On Feb 7, 2013, at 3:19 AM, Enea Zaffanella <zaffanella at cs.unipr.it> wrote:
>>> Question:
>>> is clang forcing a pointer to function to have the same size as a pointer to object?
>>
>> Undoubtedly;  this assumption is likely pervasive throughout LLVM as well.
>> Even the standards only support the alternative in theory — none of the
>> portability headers offer specific support for function pointers that disagree
>> in size with object pointers.  Even the Itanium ABI would need some very
>> interesting tweaking if you changed this.
>
> To clarify this point, I'm aware that there are platforms with this property
> and that they presumably have C compilers.  I'm just saying that the
> headers don't really go out of their way to make this easier.
>
>>> Afaict, in both cases clang ends up querying TargetInfo::PointerWidth
>>> (unless the object is placed in a non-default address space).
>>>
>>> What about differentiating behavior having, e.g.,
>>> TargetInfo::getObjectPointerWidth()
>>> and
>>> TargetInfo::getFunctionPointerWidth()
>>> ?
>>
>> My only objection to this is that it's likely to be a massively invasive and
>> never-actually-completed porting effort, on the scale of the byte-size
>> refactor.
>
> And to clarify *this* point, if somebody has an actual plan to introduce an
> LLVM backend for one of those platforms, then obviously this work
> would be welcome.  I just don't really see the point in supporting it in the
> abstract.
>
> John.


Hi John.

First of all thank you for sharing your point of view.

I am fully aware that clang is, first and mainly,

     "a C language family frontend for LLVM".

Thanks to its modular design, it is *also* an excellent frontend for 
other kinds of clients (as advertised in the web pages: refactoring, 
static analysis, code generation, etc.).

Now, let me take the point of view of, e.g., a code-refactoring or 
static analysis tool. Then, to my eyes, what really matters is the 
source code and its meaning in the considered context. Whether or not 
clang is able to produce accurate AST info even on targets that are not 
supported by LLVM is not something "in the abstract": it is a concrete 
and valuable property. On the other hand (from this limited point of 
view), what is "in the abstract" is whether or not clang properly 
supports code generation for these strange targets.

Note that the one above is, indeed, our main use of clang libraries.

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?

Enea.