[cfe-dev] The size of a pointer to function.
zaffanella at cs.unipr.it
Tue Feb 12 07:01:16 PST 2013
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.
>> 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
> 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.
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5918 bytes
Desc: not available
More information about the cfe-dev