Inline assembler in D and LDC, round 2

[Chad J]

Frits van Bommel wrote:
> Lionello Lunesu wrote:
>>
>> "Frits van Bommel" <fvbommel at REMwOVExCAPSs.nl> wrote in message
>> news:gmeqbr$1377$1 at digitalmars.com...
>>> LDC on the other hand needs to emit LLVM asm, which requires it to
>>> specify an explicit return value. My approach is a way to extract
>>> that return value from the inline asm, allowing it to emulate DMD
>>> behavior within the LLVM IR.
>>
>> Sorry, perhaps I'm missing something: Why should you have to deduct
>> that from the asm? Doesn't the function prototype give enough
>> information? If the function returns "int/uint/...", assume "eax"; if
>> it returns "float/double/..." assume "st(0)", etc....
> 
> LLVM IR doesn't know about hardware registers, except when dealing with
> inline asm. So if you need to know the value a hardware register has at
> the end of some inline asm, you need to tell that asm to "return" it
> into a virtual register that you can actually use in regular IR (such as
> returning it from a function).

I think I might just sortof maybe kinda understand the problem now.

So I take some of many options and consider the consequences:
- Don't put any return statement into the IR.  EAX/st(0)/etc has the
return value so don't bother.  Consequence:  LLVM errors, there MUST be
a return value represented in IR.
- Put some stupid return statement into the IR, like return 0.
Consequence:  Programmer places result into EAX.  LLVM generated code
places 0 into EAX.  Function always returns 0.  Whoops.
- Mark the function as returning void.  Now we don't need to put a
return into the IR.  Consequence:  User writes something like auto bar =
foo();.  foo contains inline ASM.  But what is assigned to bar in the IR
code?  There is no way to tell the IR to assign a value from
EAX/st(0)/whatever.   EAX is set to the correct value when foo()
returns, but there is no way to USE it, so it just floats around
uselessly until it is overwritten by something else.
- Casting fun.  So the function returns an integer.  Well, return a
floating point value NaN instead.  EAX still gets set to the correct
value due to the inline ASM.  Consequences:  Similar problem as before:
int bar = foo(); violates type safety since we've rewritten foo() so
that LLVM thinks it returns a float.  I don't know if the IR has any
loopholes, but if it does then maybe there is some snowball's chance in
hell of making it work anyways.

I hope I understand this correctly.  It seems like the problem at hand
is difficult to communicate and thus stomps useful dialog :(