[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