Question:
is clang forcing a pointer to function to have the same size as a pointer to object?
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()
?
(Same thing for PointerAlign and PtrDiffType.)
Enea.
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.
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.
John.
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.
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 ...
Enea.
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. To me, that does not seem like a good use of my time as a reviewer/maintainer. 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.
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.
FunctionPointerWidthAlign.patch (5.78 KB)
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.
Who is MSP430 maintainer?
I've just read in this page https://www.fooe.net/trac/llvm-msp430/ that
indeed the people involved in llvm msp430 backend plan to add:
- MSP430X support (specifically, near/far pointers)
Is this what you wanted to accept this patch?
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?
Anton.
I've just read in this page https://www.fooe.net/trac/llvm-msp430/ that
indeed the people involved in llvm msp430 backend plan to add:- MSP430X support (specifically, near/far pointers)
Is this what you wanted to accept this patch?
That page hasn't been touched since a small flurry of activity three years ago.
That is not an actual plan; that is some people getting briefly excited by a
project and then abandoning it, which (to be frank) is an excellent summation
of the history of LLVM's MSP430 support.
Please just maintain your patch privately.
John.