Frits van Bommel wrote: > Lionello Lunesu wrote: >> >> "Frits van Bommel" <fvbom...@remwovexcapss.nl> wrote in message >> news:gmeqbr$137...@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 :(