Hello,
clang currently seems to generate the same code for both:
double something_a(char A[const static 256]) {
...
}
and for:
double something_b(char (*const A)) {
...
}
even though in the first case the programmer has told us that the array
A is at least 256 bytes in length (and, thus, will not be null). Do we
currently have a way to pass this information to LLVM?
Thanks again,
Hal
--
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory
On Mon, Sep 10, 2012 at 2:43 PM, Hal Finkel <hfinkel at anl.gov> wrote:> Hello, > > clang currently seems to generate the same code for both: > > double something_a(char A[const static 256]) { > ... > } > > and for: > > double something_b(char (*const A)) { > ... > } > > even though in the first case the programmer has told us that the array > A is at least 256 bytes in length (and, thus, will not be null). Do we > currently have a way to pass this information to LLVM?No. -Eli
Hal Finkel wrote:> Hello, > > clang currently seems to generate the same code for both: > > double something_a(char A[const static 256]) { > ... > } > > and for: > > double something_b(char (*const A)) { > ... > } > > even though in the first case the programmer has told us that the array > A is at least 256 bytes in length (and, thus, will not be null). Do we > currently have a way to pass this information to LLVM?No, but I'm interested in this. C++ references imply that 'n' bytes of the pointer may be dereferenced, and we have no way of capturing that fact. It would feed into llvm::isSafeToLoadUnconditionally(). Nick
On Mon, 10 Sep 2012 17:40:43 -0700 Nick Lewycky <nicholas at mxc.ca> wrote:> Hal Finkel wrote: > > Hello, > > > > clang currently seems to generate the same code for both: > > > > double something_a(char A[const static 256]) { > > ... > > } > > > > and for: > > > > double something_b(char (*const A)) { > > ... > > } > > > > even though in the first case the programmer has told us that the > > array A is at least 256 bytes in length (and, thus, will not be > > null). Do we currently have a way to pass this information to LLVM? > > No, but I'm interested in this. C++ references imply that 'n' bytes > of the pointer may be dereferenced, and we have no way of capturing > that fact. It would feed into llvm::isSafeToLoadUnconditionally().At the risk of starting yet another metadata proposal discussion, shall we add some metadata to describe this? These cases could be handled by metadata with an integer parameter. Is there a reasonable way of handling cases like: void foo(int n, int q[n][n]) { ... } ? -Hal> > Nick-- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory
On Mon, Sep 10, 2012 at 16:43:57 -0500, Hal Finkel wrote:> clang currently seems to generate the same code for both: > > double something_a(char A[const static 256]) { > ... > } > > and for: > > double something_b(char (*const A)) { > ... > } > > even though in the first case the programmer has told us that the array > A is at least 256 bytes in length (and, thus, will not be null).Is this really the case? In what language(s)? As I understand it, the C99 standard simply states that a function argument declared as "array of T" is equivalent to "pointer to T", so it does not really guarantee anything about whether the argument is a non-null pointer to a valid array of the given number of elements. -- Gergö Barany, research assistant gergo at complang.tuwien.ac.at Institute of Computer Languages http://www.complang.tuwien.ac.at/gergo/ Vienna University of Technology Tel: +43-1-58801-58522 Argentinierstrasse 8/E185, 1040 Wien, Austria Fax: +43-1-58801-18598
> Is this really the case? In what language(s)? As I understand it, the C99 > standard simply states that a function argument declared as "array of T" is > equivalent to "pointer to T","static" is special though. 6.7.5.3p7 says: "If the keyword static also appears within the [ and ] of the array type derivation, then for each call to the function, the value of the corresponding actual argument shall provide access to the first element of an array with at least as many elements as specified by the size expression". In practice, this mostly just means a compiler can access the specified number of elements with impunity. In theory you could have a situation where arrays were allocated differently to normal pointers and do even less checks (or perhaps look at a cookie before each array giving its real length...) Tim.