Problem with code generated for call using stdcall convention

Hi, I’m trying to run the following module in lli on LLVM 2.6, Windows/MSVS 2008, 32 bits memory model:

Hello

Is the x86_stdcallcc call convention actually supported? I found it by
digging into LLVM sources

Yes. It's fully supported.

Is my initial LLVM-IR correct for invoking WIN32 API function?

No. You forgot to put calling convention on the call itself.

2009/12/9 Anton Korobeynikov <anton@korobeynikov.info>

Hello

Is my initial LLVM-IR correct for invoking WIN32 API function?

No. You forgot to put calling convention on the call itself.

Thanks, this work great!

I naively though it would pick up the call convention from the declaration as there was no error like we have when the wrong number of parameters is used.

Hello

I naively though it would pick up the call convention from the declaration
as there was no error like we have when the wrong number of parameters is
used.

This is not an error, you're just invoking undefined behaviour.

When we first encountered problems with our calling conventions, my
first thought was that clearly the calling convention should be part
of the function type. The response from jyasskin was that types are
immutable, and LLVM wants to be able to modify calling conventions at
will. I wondered why not then allocate a new type from the context.
Is this possible? It seems like it would be a better design, although
it doesn't really impact us that much, and I'm not pushing for this
change.

Everyone seems to stumble on forgetting to set the calling convention
on both the call site and the function object. Moving the convention
into the type would fix this, since most people already just pick the
type off of the appropriate declaration.

Reid

I too have stumbled over this.

Wouldn't it be a good idea to add a check for this to the function verifier pass?

Hans

Anton Korobeynikov wrote:

Hi,

Wouldn't it be a good idea to add a check for this to the function verifier pass?

no, because it is valid. The problem is that the optimizers can expose
this kind of thing. For example, imagine you have an indirect call, where
the calling convention is CC_X. Suppose the optimizers are able to deduce
the function that is being called, say F, and turn the call into a direct
call to F. If the calling convention for F is different, say CC_Y, then
having the verifier reject the bitcode because CC_X != CC_Y would result
in a compiler crash. So you would have to teach all kind of optimizers
to be careful because they might turn a valid program into an invalid one.
That's too painful.

Ciao,

Duncan.

Hans Wennborg wrote:

I too have stumbled over this.

Wouldn't it be a good idea to add a check for this to the function
verifier pass?

No. This is a FAQ: http://llvm.org/docs/FAQ.html#callconvwrong

Nick

IMO you could move the cc to the type and still replace mismatched
calls with unreachable. Are there other design considerations for not
doing this?

Reid

Reid Kleckner wrote: