Re: [LLVMdev] inline asm semantics: output constraint width smaller than input

From: Chris Lattner
Date: Sat Jan 24 2009 - 14:31:22 EST



On Jan 24, 2009, at 9:27 AM, Ingo Molnar wrote:

#define __put_user_size(x, ptr, size, retval, errret) \
diff --git a/arch/x86/lib/delay.c b/arch/x86/lib/delay.c
index f456860..12d27f8 100644
--- a/arch/x86/lib/delay.c
+++ b/arch/x86/lib/delay.c
@@ -112,7 +112,7 @@ EXPORT_SYMBOL(__delay);

inline void __const_udelay(unsigned long xloops)
{
- int d0;
+ unsigned long d0;

xloops *= 4;
asm("mull %%edx"

Is this all that you need (plus the 16-bit setup code tweaks) to get LLVM
to successfully build a 64-bit kernel image?

If yes then this doesnt look all that bad or invasive at first sight (if
the put_user() workaround can be expressed in a cleaner way), but in any
case it would be nice to hear an LLVM person's opinion about roughly when
this is going to be solved in LLVM itself.

Hi Ingo,

We would like to support some more specific cases (e.g. when tying a pointer/int to a different size pointer/int) but we currently don't intend to support all cases (e.g. tying a FP value to int). We are in this position because the semantics are very vague and hard to reason about (and change based on target endianness) and we had many subtle bugs in the corner cases.

Instead of having silent miscompiles, we decided to just reject all the "hard" cases and add them back one by one as there is demand. That way users could choose to modify their asms instead of having them be potentially silently miscompiled.

LLVM 2.5 is in its release process right now, so it will not have improvements in this area, but LLVM 2.6 certainly could. If there is interest in building the kernel with 2.5, I think taking the patches would be worthwhile. If that is hopeless anyway, waiting for the LLVM- side fixes should be fine.

-Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/