Call to address 0 gets removed

Hello

If I optimize (opt -std-compile-opts ) the following .ll

; ModuleID = ‘call0.ll’
target datalayout = “e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32”
target triple = “i386-mingw32”

define i32 @t(i32 %a) nounwind {
entry:
%0 = tail call i32 inttoptr (i32 0 to i32 (i32)*)(i32 %a) nounwind ; [#uses=1]
ret i32 %0
}

The call to address 0 gets removed.

define i32 @t(i32 %a) noreturn nounwind readnone {
entry:
unreachable
}

How can I prevent that the call is removed, without making the function addr volatile?
Does anyone know which optimization removes it?

Thanks,
Marius Wachtler

Calling 0 is undefined behavior; the optimizer is within its rights to remove this. Why do you want to call 0?

Calling 0 is undefined behavior; the optimizer is within its rights to
remove this. Why do you want to call 0?

For example, on embedded platforms you call 0 to do a soft reset.

Sylvere Teissier wrote:

Calling 0 is undefined behavior; the optimizer is within its rights to remove this. Why do you want to call 0?

For example, on embedded platforms you call 0 to do a soft reset.

You can do this using an asm. Since you are acting outside the C
standard, this is probably "the right way" of doing it (tm).

Ciao,

Duncan.

2009/6/10 Sylvere Teissier <st@invia.fr>

Calling 0 is undefined behavior; the optimizer is within its rights to
remove this. Why do you want to call 0?

For example, on embedded platforms you call 0 to do a soft reset.

I suggest you create an intrinsic named @llvm.mybackend.reset if that’s your goal. It can then lower to any instruction sequence you want, including call 0.

Nick