[LLVMdev] llvm-gcc: code generated for pre- and post-increment

Steve Montgomery stephen.montgomery3 at btinternet.com
Fri Oct 8 07:51:21 PDT 2010


I'm relatively new to LLVM so apologies in advance if this is a dumb  
question. I've been experimenting with re-targeting LLVM onto a 16-bit  
micro which has pre and post increment and decrement addressing modes.  
I've been using llvm-gcc to generate llvm bitcode and llvm 2.7 to go  
from here to my target assembly code.

I've got the Combine pass to deal with post-increment/decrement modes  
without any difficulty but I can't seem to get pre-increment/decrement  
modes to work. If I examine the bitcode for:

char c, *p;

void func(void)
{
   c = *++p;
}

then I get (with llvm-gcc 4.2.1):

%0 = load i8** @p, align 4
%1 = getelementptr inbounds i8* %0, i32 1
store i8* %1, i8** @p, align 4
%2 = load i8*, %1, align 1
store i* %2m i8* @c, align 1

I think the position of the first store is preventing  
DAGCombiner::CombineToPreIndexedLoadStore from folding the base  
pointer (test #3 out of the 4 tests it makes). If I move that store  
into p to the end of the code then it's happy to fold it.

Why does llvm-gcc emit llvm code that seems to preclude the combiner  
from ever being able to combine a pre-increment/decrement? Given that  
the order of side-effects between sequence points is unspecified and  
the behaviour undefined if any object is modified more than once  
between sequence points it seems to me to be perfectly legal to move  
that first load to the end.

In passing, I note that the clang front-end seems to emit code that  
will never be a candidate for folding into either pre or post  
increment/decrement operations.

Steve Montgomery




More information about the llvm-dev mailing list