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

* Török Edwin <edwintorok at gmail.com> wrote: > On 2009-01-23 20:27, Török Edwin wrote: > >>> > >>> > >> i'd not mind it at all if the kernel could be built with other open-source > >> compilers too. > >> > >> Now in this case the patch you suggest might end up hurting the end result > >> so it's

On 2009-01-23 20:27, Török Edwin wrote: >>> >>> >> i'd not mind it at all if the kernel could be built with other open-source >> compilers too. >> >> Now in this case the patch you suggest might end up hurting the end result >> so it's not an unconditional 'yes'. But ... how much it actually matters >> depends on

On 2009-01-24 19:27, Ingo Molnar wrote: > * Török Edwin <edwintorok at gmail.com> wrote: > >> #define put_user(x, ptr) \ >> ({ \ >> - int __ret_pu; \ >> + __typeof__(*(ptr)) __ret_pu; \ >> > > This does not look right. We can sometimes have

On 2009-01-27 23:00, Chris Lattner wrote: > Right, the interesting wrinkle is that I think llvm's codegen should > only see matching constraints of the same type. If the front-end sees > an i8 tied to an i32, it should extend the i8 or do whatever else it > needs to do. > My only concern is whether codegen will be able to optimize away extra extensions/truncations or

On 2009-01-27 22:24, Duncan Sands wrote: > On Tuesday 27 January 2009 20:56:30 Mike Stump wrote: > >> On Jan 27, 2009, at 8:42 PM, Duncan Sands wrote: >> >>> one thing that seems to be clear to everyone except me is... what >>> are the >>> semantics supposed to be? >>> >> I don't know of any other semantic other than,

On Jan 27, 2009, at 12:36 PM, Török Edwin wrote: > On 2009-01-27 22:24, Duncan Sands wrote: >> On Tuesday 27 January 2009 20:56:30 Mike Stump wrote: >> >>> On Jan 27, 2009, at 8:42 PM, Duncan Sands wrote: >>> >>>> one thing that seems to be clear to everyone except me is... what >>>> are the >>>> semantics supposed to be?

On Tuesday 27 January 2009 20:56:30 Mike Stump wrote: > On Jan 27, 2009, at 8:42 PM, Duncan Sands wrote: > > one thing that seems to be clear to everyone except me is... what > > are the > > semantics supposed to be? > > I don't know of any other semantic other than, if they are supposed to > be in the same register, then they have to be in the same register.

On Jan 27, 2009, at 8:42 PM, Duncan Sands wrote: > one thing that seems to be clear to everyone except me is... what > are the > semantics supposed to be? I don't know of any other semantic other than, if they are supposed to be in the same register, then they have to be in the same register.

Hi Chris, > > LLVM's Codegen is rejecting inline asm when input/output constraints > > have different bitwidths. > > > > For example in the Linux kernel calls to the various __put_user_ > > functions take %al, %ax, %eax, %rax/ (%eax:%edx) as input parameter, > > and the output parameter is always an int (%eax). (hope I explained > > this > >

On Wed, Jan 28, 2009 at 12:29 PM, H. Peter Anvin <hpa at zytor.com> wrote: > Kyle Moffett wrote: >> Even in the 64-bit-integer on 32-bit-CPU case, you still end up with >> the lower 32-bits in a standard integer GPR, and it's trivial to just >> ignore the "upper" register. You also would not need to do any kind >> of bit-shift, so long as your inline

Kyle Moffett wrote: > > Even in the 64-bit-integer on 32-bit-CPU case, you still end up with > the lower 32-bits in a standard integer GPR, and it's trivial to just > ignore the "upper" register. You also would not need to do any kind > of bit-shift, so long as your inline assembly initializes both GPRs > and puts the halves of the result where they belong. >

Kyle Moffett wrote: > > Actually, PPC64 boxes basically don't care... the usable GPRs are all > either 32-bit (for PPC32) or 64-bit (for PPC64), the <=32-bit > instructions are identical across both, they just > truncate/sign-extend/etc based on the lower 32-bits of the register. > Also, you would only do a right-shift if you were going all the way > out to memory as

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

On Tue, Jan 27, 2009 at 8:56 PM, H. Peter Anvin <hpa at zytor.com> wrote: > Kyle Moffett wrote: >> Actually, PPC64 boxes basically don't care... the usable GPRs are all >> either 32-bit (for PPC32) or 64-bit (for PPC64), the <=32-bit >> instructions are identical across both, they just >> truncate/sign-extend/etc based on the lower 32-bits of the register.

On Tue, Jan 27, 2009 at 4:25 PM, H. Peter Anvin <hpa at zytor.com> wrote: > However, things get a bit ugly in the case of different widths that affect > individually scheduled registers, like 32- and 64-bit types on a 32-bit > machine. Consider the case above where "bar" is a 64-bit type and "baz" is > a 32-bit type, then you functionally have, at least on

Hi, > 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. one thing that seems to be clear to everyone except me is... what are the semantics supposed to be? [My

Duncan Sands wrote: > Hi, > >> 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. > > one thing that seems to be clear to everyone

Here's a brief update on the current state of 16-bit x86 support... The assembler has support for the .code16 directive and can happily output 16-bit code. In pending patches¹ I have also added an i386-*-*-code16 triple and fixed the disassembler to support 16-bit mode (which was previously present, but could not be invoked and was fairly broken). And added a '-m16' option to clang.

> On Fri, Aug 3, 2012 at 3:09 PM, Torfinn Ingolfsen > <torfinn.ingolfsen@getmail.no> wrote: > > Just a short update on this machine (Acer Aspire X1470) and the GPT / UEFI situation. > > Today I set up another partition, EFI system partition. The partyitions now looks like this: > > root@kg-vm2# gpart show ada0 > > => 34 250069613 ada0 GPT (119G)

Recently under amd64 and 9.1-STABLE I am seeing issues with the bce driver. Message is "Warning: bootcode thinks driver is absent". After this message, the box appears to be wedged. After rebooting, it got the same message during fsck. So we installed 9.2 pre-release using a snapshot iso from 7/13/13. Shortly after boot we got the same message. We are now in the process of