[llvm-commits] [llvm] r116665 - in /llvm/trunk: include/llvm/CodeGen/MachineModuleInfo.h lib/CodeGen/MachineModuleInfo.cpp lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp lib/Target/X86/X86AsmPrinter.cpp test/CodeGen/X86/fltused.ll

[Michael Spencer]

On Sat, Oct 16, 2010 at 8:08 AM, Duncan Sands <baldrick at free.fr> wrote:
> Hi Michael,
>
>> X86-Windows: Emit an undefined global __fltused symbol when targeting Windows
>> if any floating point arguments are passed to an external function.
>
> why?

Because the Microsoft C standard library requires it. If you don't
printf("%f", 1.0); would fail via a call to abort. An unknown set of
functions have this behavior.

>> +    // See if any floating point values are being passed to this external
>> +    // function. This is used to emit an undefined reference to fltused on
>> +    // Windows.
>
> An indirect call could be to an external function, but you will not get to your
> logic in the case of an indirect call.  A call to a varargs function could pass
> a floating point value, but you will not catch that using your approach.  I
> think you should be looking at the call-site not the callee.

You are correct about indirect calls. As for varargs, the test I added
was explicitly for printf. The CallInst is the call-site. I only use
the function type to avoid checking function calls which obviously
cannot lead to library calls.

Although this does lead me to believe that only vararg functions
require this treatment. It would be nice if Microsoft had any actual
documentation on __fltused.

>> +    if (!F->hasLocalLinkage()&&  F->hasName()) {
>
> Why is having a name relevant here?

The intention was to only check library functions or external
functions which could call library functions. Although indirect calls
violate this case.

> Ciao,
>
> Duncan.

Thanks for the review!

- Michael Spencer