llvm dev - Sep 2012 - [LLVMdev] Minimum Array Size

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.