similar to: [LLVMdev] Make PPC JIT support inline assembly?

Hi, Very few inline assembly are supported for the X86 backend. As I see from X86ISelLowering.cpp, only bswap, rorw, xchgl and simple register selections (e.g. {=r10}) LLVM JIT can recoginze. But for PPC backend, I am not sure why PPC JIT see all inline assembly IRs as an error. Ding-Yong On Thu, Mar 24, 2011 at 2:53 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi 陳韋任, > >

Hi 陳韋任, > It seems PPC JIT does not recognize inline assembly. > For example, when I give LLVM IR belows to PPC JIT, > > %0 = tail call i32* asm "", "={r10}"() nounwind ;<i32*> [#uses=1] > > it complaints that inline assembly is not a supported > instruction. x86 JIT works fine, however. I'm surprised this worked with the x86 JIT - I

Hi, Duncan > support any inline assembler on any platform, and that the plan was to > solve this with the new MC-JIT, see > http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html At the first glance, I think what llvm-mc does is, given an input, llvm-mc will disassemble the input into assembly. I don't know the MC-JIT you mentioned can be used as a JIT. Currently, a JIT is

Hi, Duncan > it is not in llvm-2.8, it will not even be in llvm-2.9. This is why you > couldn't find it :) Some patches went into the subversion repository > lately if you are interested. You mentioned "the plan was to solve this with the new MC-JIT". You mean that MC-JIT can handle inline assembly as an input, and generate target binary code? Regards, chenwj --

Hi chenwj, >> support any inline assembler on any platform, and that the plan was to >> solve this with the new MC-JIT, see >> http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html > > At the first glance, I think what llvm-mc does is, given an input, > llvm-mc will disassemble the input into assembly. I don't know the > MC-JIT you mentioned can be

Hi chenwj, >> it is not in llvm-2.8, it will not even be in llvm-2.9. This is why you >> couldn't find it :) Some patches went into the subversion repository >> lately if you are interested. > > You mentioned "the plan was to solve this with the new MC-JIT". You > mean that MC-JIT can handle inline assembly as an input, and generate > target binary

Hi, I see. Thanks. :-) One more question, how mature MC-JIT is? Can it be used on x86 or other architecture? Regards, chenwj -- Wei-Ren Chen (陳韋任) Parallel Processing Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667

Hi, all What I want to do is to locate the range of a for-loop statement in a binary. For example, given a for-loop statement belows, for (stat1; stat2; stat3) { /* do something */ } Is it possible to get information about the range (binary address) of the above for-loop, say, 0x0100 - 0x0120. One idea comes up in my mind is adding passes to retrieve such information in LLVM, then use

Hi chenwj, > One more question, how mature MC-JIT is? Can it be used on > x86 or other architecture? my understanding is that it is not yet usable. Ciao, Duncan.

Hi, folks I don't know if this is a bug or not? But the way how llvm-gcc on ppc handles inline assembly is different from the one on x86. For example, here is the example code: ----------------------------------------- register int *a asm("r10"); int main() { *a = 1; return 0; } ----------------------------------------- llvm-gcc on x86 produces LLVM IR belows,

In general, this is not possible. Consider, for example, the fact that various optimization passes may reorder the code, including such things as hoisting computations outside of the loop, and enclosing loops, scheduling those instructions before others that did not originate from source lines within the loop, etc. That's not to mention things like loop unrolling. That said, especially at low

Hi, both https://git.kernel.org/pub/scm/libs/klibc/klibc.git/plain/usr/klibc/arch/i386/libgcc/__ashldi3.S and https://git.kernel.org/pub/scm/libs/klibc/klibc.git/plain/usr/klibc/arch/i386/libgcc/__lshrdi3.S use the following code sequences for shift counts greater 31: 1: 1: xorl %edx,%edx shrl %cl,%edx shl %cl,%eax xorl %eax,%eax

>> 2) Same error but some diff. problem with AlphaCodeEmitter.cpp and >> PPCCodeEmitter.cpp: >> >> GCC don't like definition member-functions in global namespace with >> declaration in llvm::<unnamed> : Sorry for wrong comment. Must be: GCC 4.1.0 don't like definition member-functions in llvm namespace with declaration in

On Mon, 24 Oct 2005, Vladimir A. Merzliakov wrote: >>> 2) Same error but some diff. problem with AlphaCodeEmitter.cpp and >>> PPCCodeEmitter.cpp: >>> >>> GCC don't like definition member-functions in global namespace with >>> declaration in llvm::<unnamed> : > > Sorry for wrong comment. > Must be: > GCC 4.1.0 don't like

Hi, all On the dragonedd website, there is a line "It is a reimplementation of llvm-gcc that works with gcc-4.5 or later." I am trying to make gcc-4.6 work woth dragonegg, but I get an error belows, ------------------------------------------------------------------------ Compiling cache.c /tmp/chenwj/dragonegg-2.9/cache.c: In function 'llvm_set_cached':

"H. Peter Anvin" <hpa at zytor.com> wrote August 20, 2019 12:51 AM: > On 8/14/19 9:42 PM, Stefan Kanthak wrote: >> Hi, >> >> both >> https://git.kernel.org/pub/scm/libs/klibc/klibc.git/plain/usr/klibc/arch/i386/libgcc/__ashldi3.S >> and >> https://git.kernel.org/pub/scm/libs/klibc/klibc.git/plain/usr/klibc/arch/i386/libgcc/__lshrdi3.S

On Wed, Jul 23, 2008 at 11:24:49AM +0200, Karel Zak wrote: > On Wed, Jul 23, 2008 at 04:43:30AM -0400, Christoph Hellwig wrote: > > On Wed, Jul 23, 2008 at 10:39:38AM +0200, maximilian attems wrote: > > > klibc mount has only short options thus uses the following syntax > > Frankly, it seems like a klibc problem... well not directly, but right klibc-utils should have

hi, I'm just recoginze that dovecot contains an rpm spec file. unfortunately it's not too useful since an rpm -ta dovecot-.x.y.tar.gz can't be used since just the dovecot.spec.in is in the tarbar and not the actual spec file (which is in this from not useful in the above form). anyway here is my patch to the spec.in. -- Levente "Si vis pacem

Hi, I tried to enable virtio-blk data plane feature for VMs in my openstack environment, the hypervisor is ubuntu 14.04, libvirt 1.2.2 and QEMU 2.0. As nova doesn't support that parameter yet, I did belows 1. nova boot a VM with raw disk image. 2. nova stop the VM. 3. run "virsh edit <instance-id>" on the hyprvisor node, and adding below into instance xml just before

On Mon, 24 Oct 2005, Vladimir A. Merzliakov wrote: > I have some problems with build current CVS version LLVM using GCC 4.1.0 (GCC > CVS mainline version). Thanks! > 1) Build terminate with error: > > llvm[3]: Compiling SparcV8CodeEmitter.cpp for Debug build > /usr/home/wanderer/pkg/build/llvm/obj/lib/Target/SparcV8/SparcV8GenCodeEmitter.inc:11: > error: definition of