[LLVMdev] nested GEP in a static initializer fails

Nick Lewycky nicholas at mxc.ca
Tue Oct 26 00:12:03 PDT 2010


Joel E. Denny wrote:
> Hi,
>
> Given this LLVM assembly:
>
>    @a = global i8* getelementptr (i8* null, i64 mul (i64 ptrtoint (i32* getelementptr (i32* null, i32 1) to i64), i64 2))
>
> llc fails an assertion:
>
>    llc: /home/jdenny/llvm-svn/include/llvm/Support/Casting.h:202: typename llvm::cast_retty<To, From>::ret_type llvm::cast(const Y&) [with X = llvm::ConstantInt, Y = llvm::Value*]: Assertion `isa<X>(Val)&&  "cast<Ty>() argument of incompatible type!"' failed.
>
> This has been reported previously as a bug and was resolved as invalid:
>
>    http://llvm.org/bugs/show_bug.cgi?id=2672
>
> The explanation was:
>
> "I don't think we should try to fold arbitrary expressions in the code
> generator.  Instead, we should accept that targets have limitations on
> these.  We can't ever support things like "void *X =&G /&H;" for
> example."
>
> Are the limitations on what can be placed in a static initializer
> documented somewhere?

No.

   When those limitations aren't obeyed, would it be
> possible for llc to print a more intelligible error message for the user?

The limitations are a product of the ABI and on-disk .o file format. For 
example, given "int X = (int)&G / (int)&H;", llc will happily generate 
"X: .long G/H" which is invalid assembly, but llc doesn't know that.

Maybe with the MC infrastructure we could start to figure out what is 
and isn't representable. That would be nice since the frontend may need 
to change its behaviour, for example, GCC lowers the example code into a 
C++ static initializer function to calculate the value for X at load 
time before main() starts. As of today, llvm-gcc and clang both get this 
wrong.

Nick



More information about the llvm-dev mailing list