All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Török Edwin" <edwintorok@gmail.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	LLVM Developers Mailing List <llvmdev@cs.uiuc.edu>
Subject: Re: inline asm semantics: output constraint width smaller than input
Date: Fri, 23 Jan 2009 22:42:47 +0200	[thread overview]
Message-ID: <497A2BC7.5030107@gmail.com> (raw)
In-Reply-To: <497A11F5.9090005@gmail.com>

On 2009-01-23 20:52, Török Edwin wrote:
> On 2009-01-23 20:30, Ingo Molnar wrote:
>   
>> * Török Edwin <edwintorok@gmail.com> wrote:
>>
>>   
>>     
>>> Having said that, llvm-gcc is not yet able to compile the full Linux 
>>> kernel on its own [for example the boot code, due to asm(".code16gcc")], 
>>> but with LLVM 2.4 it was possible to build "arch=UM", and "arch=X86" (by 
>>> using gcc to build the bootcode). I'd like LLVM 2.5 to be able to build 
>>> the kernel, so I'll file bugs for llvm/kernel depending on where the 
>>> problem is.
>>>     
>>>       
>> Could we get LLVM folks on the Cc: and see how difficult it would be to 
>> fix this on the LLVM side? Asm constraints are used all around the place 
>> and different input/output types are very common.
>>     
>
>   

Hi Ingo,

Could you describe what are the semantics you need for inline asm
constraints in the kernel?
GCC doesn't document all the corner cases, and defining inline asm =
"whatever gcc accepts" is not very useful for LLVM.

So far we've encountered the problem with input/output operand tied to
same register, but having different widths:
- output wider than input, both integers: do you need this case?
- output narrower than input, both integers: this is the common case, right?
- can it also happen that input is pointer, output is integer of
different width?
- .. any other mismatches?

Could you also describe why put_user/the example from pcbios needs the
different widths?

Best regards,
--Edwin

  reply	other threads:[~2009-01-23 20:43 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-23 17:57 inline asm semantics: output constraint width smaller than input Török Edwin
2009-01-23 18:17 ` Ingo Molnar
2009-01-23 18:21   ` H. Peter Anvin
2009-01-23 18:27   ` Török Edwin
2009-01-23 18:30     ` Ingo Molnar
2009-01-23 18:52       ` Török Edwin
2009-01-23 20:42         ` Török Edwin [this message]
2009-01-24 16:23     ` Török Edwin
2009-01-24 17:27       ` Ingo Molnar
2009-01-24 18:57         ` Török Edwin
2009-01-24 21:25           ` [LLVMdev] " Mike Stump
2009-01-24 19:23         ` Chris Lattner
2009-01-24 21:10           ` H. Peter Anvin
2009-01-27 19:42         ` Duncan Sands
2009-01-27 21:25           ` H. Peter Anvin
2009-01-28  1:45             ` Kyle Moffett
2009-01-28  1:56               ` H. Peter Anvin
2009-01-28 13:28                 ` Kyle Moffett
2009-01-28 17:29                   ` H. Peter Anvin
2009-01-28 19:27                     ` Kyle Moffett
2009-01-28 20:59                       ` H. Peter Anvin
2009-01-24 20:07       ` Andreas Schwab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=497A2BC7.5030107@gmail.com \
    --to=edwintorok@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llvmdev@cs.uiuc.edu \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.