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/