Thursday Jan 27, 2011

Don't initialise local strings

Consider the following code:

void s(int i)
{
  char string[2048]="";
  sprinf(string,"Value = %i",i);
  printf("String = %s\\n",string);
}

The C standards require that if any elements of the character array string are initialised, then all of them should be. We can demonstrate this by compiling with gcc:

$ gcc -O -S f.c
$ more f.s
        .file   "f.c"
...
        .type   s, #function
        .proc   020
s:
        save    %sp, -2160, %sp
        stx     %g0, [%fp-2064]
        add     %fp, -2056, %o0
        mov     0, %o1
        call    memset, 0
        mov    2040, %o2

You can see that explicitly initialising string caused all elements of string to be initialised with a call to memset(). Removing the explicit initialisation of string (the ="") avoids the call to memset().

Sunday Oct 03, 2010

Memory ordering

Just had a couple of white papers published on memory ordering. This is a topic which is quite hard to find documentation on, and also quite complex. Fortunately, it's also rarely encountered.

In Oracle Solaris Studio 12.2 we introduced the file mbarrier.h. This defines some intrinsics which allow the developer to enforce memory ordering.

The first paper covers avoiding the reordering of memory operations that the compiler may perform when compiling an application. The second paper covers the more complex issue of avoiding the reordering of memory operations that the processor may do at runtime.

Thursday Mar 26, 2009

OpenSPARC workshop - Brussels

April 24th and 25th I'm going to be in Brussels rerunning the OpenSPARC workshop. The workshop leverages the material in the OpenSPARC Internals book, together with the OpenSPARC presentations. There's a poster with all the details (for those with acute eyesight, the poster on the left is from the December workshop!).

Wednesday Nov 05, 2008

OpenSPARC workshop in London

I'm thrilled to have been asked to present at the OpenSPARC workshop to be run in London, on December 4 and 5th. I'll be covering the 'software topics'. There's no charge for attending the workshop.

Monday Oct 27, 2008

x86 compiler flags

This AMD document summarises the optimisation flags available for many x86 compilers (Sun Studio, PGI, Intel etc.). It's about a year old, but it looks ok for Sun Studio. However it talks about -xcrossfile which is ancient history - use -xipo instead!

Thursday May 15, 2008

Crossfile inlining and inline templates

Found an interesting 'feature' of using crossfile (-xipo) optimisation together with inline templates. Suppose you have a 'library' routine which is defined in one file and uses an inline template. This library routine is used all over the code. Here's an example of such a routine:

int T(int);
int W(int i)
{
 return T(i);
}

The routine W relies on an inline template (T) to do the work. The inline template contains some code like:

.inline T,0
  add  %o0,%o0,%o0
.end

The main routine resides in another file, and uses the routine W:

#include 
int W(int);
void main()
{
  printf("%i\\n",W(9));
}

To use inline templates you compile the file that contains the call to the inline template together with the inline template that it calls - like this:

$ cc -c -xO4 m.c
$ cc -c -xO4 w.c t.il
$ cc -xO4 m.o w.o

However, when crossfile optimisation (-xipo) is used, the routine W is inlined into main, and now main has a dependence on the inline template. But when m.o is recompiled after W has been inlined into main, the compiler cannot see the inline template for T because it was not present on the initial compile line for m.c. The result of this is an error like:

$ cc -c -xO4 -xipo m.c
$ cc -c -xO4 -xipo w.c t.il
$ cc -xO4 -xipo m.o w.o
Undefined                     first referenced
 symbol                             in file
T                                   m.o
ld: fatal: Symbol referencing errors. No output written to a.out

As you might guess from the above description, the workaround is not intuitive. You need to add the inline template to the initial compile of the file m.c:

$ cc -c -xO4 -xipo m.c t.il
$ cc -c -xO4 -xipo w.c t.il
$ cc -xO4 -xipo m.o w.o

It is not sufficient to add the inline template to the final compile line.

Looking beyond the simple test case shown above, the problem really is that when crossfile optimisation is used, the developer is no longer aware of the places in the code where inlining has happened (which is as it should be). So the developer can't know which initial compile lines to add the inline template to.

Hence, the conclusion is that whenever you are compiling code that relies on inline templates with crossfile optimisation, it is necessary to include the inline template on the compile line of every file.

Friday May 02, 2008

OpenSolaris Summit

I'm stepping in to present at the OpenSolaris Summit on Sunday. The presentation is titled "Optimizing for OpenSolaris", and I believe someone else has already prepared the slideset - we'll see. Anyway, I'm looking forward to going, the attendees list contains many familiar names.

About

Darryl Gove is a senior engineer in the Solaris Studio team, working on optimising applications and benchmarks for current and future processors. He is also the author of the books:
Multicore Application Programming
Solaris Application Programming
The Developer's Edge

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
5
6
8
9
10
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Bookmarks
The Developer's Edge
Solaris Application Programming
Publications
Webcasts
Presentations
OpenSPARC Book
Multicore Application Programming
Docs