Cc: =?ISO-8859-1?Q?T=F6r=F6k_Edwin?= <edwintorok@gmail.com>,
       Thomas Gleixner <tglx@linutronix.de>,
       Linux Kernel <linux-kernel@vger.kernel.org>,
       "H. Peter Anvin" <hpa@zytor.com>
Message-Id: <9A54B928-B0FA-46E9-B963-E24C642F09DA@apple.com>
From: Chris Lattner <clattner@apple.com>
To: LLVM Developers Mailing List <llvmdev@cs.uiuc.edu>
In-Reply-To: <20090124172758.GA31699@elte.hu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: [LLVMdev] inline asm semantics: output constraint width smaller than	input
Date: Sat, 24 Jan 2009 11:23:18 -0800
References: <497A0500.3080706@gmail.com> <20090123181721.GA32545@elte.hu> <497A0C0A.7080207@gmail.com> <497B408C.20802@gmail.com> <20090124172758.GA31699@elte.hu>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2093
Lines: 56


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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/