similar to: [LLVMdev] [Patch] Thumb BLXr doesn't set the register operand

On 13 May 2011 06:42, Koan-Sin Tan <koansin.tan at gmail.com> wrote: > With that attached patch, we can compile and run some (not all) Android > NDK samples without problem. Hi Koan, Have you tried to run Intel and other platform tests? I feel uncomfortable with so many changes in generic MC/ELF regarding specific ARM support... not to mention the magic variables on shifts... ;)

Hi, We are trying to use clang as a drop-in replacement for the gcc come with Android NDK. I found that MC/ELF doesn't not handle Thumb functions properly, e.g., bit 0 of the function name in the .symtab is not set to 1, and some thumb instructions are not generated correctly, e.g., the addresses for tBL/tBLX are not calculated right. With that attached patch, we can compile and run some

Renato, The result of running 'llvm-lit $LLVM/TEST/MC" is: Expected Passes : 330 Expected Failures : 20 Actually it passed "make check", no unexpected result. On Fri, May 13, 2011 at 5:14 PM, Renato Golin <renato.golin at arm.com> wrote: > On 13 May 2011 06:42, Koan-Sin Tan <koansin.tan at gmail.com> wrote: >> With that attached patch, we can compile

On 13 May 2011 12:16, Koan-Sin Tan <koansin.tan at gmail.com> wrote: >  The result of running 'llvm-lit $LLVM/TEST/MC" is: > Expected Passes : 330 > Expected Failures : 20 >  Actually it passed "make check", no unexpected result. Try make check-all, it runs more tests... Still, I think someone more in line with MC/ELF should have a look at the patch. Rafael?

On 11-05-13 08:15 AM, Renato Golin wrote: > On 13 May 2011 12:16, Koan-Sin Tan<koansin.tan at gmail.com> wrote: >> The result of running 'llvm-lit $LLVM/TEST/MC" is: >> Expected Passes : 330 >> Expected Failures : 20 >> Actually it passed "make check", no unexpected result. > > Try make check-all, it runs more tests... > > Still,

Hi all. I'm investigating an issue with incorrect lldb's disassembly output. I have two bytes in question: 4e5f lldb (via the llvm's LLVMARMCodeGen) is providing the following mnemonics: ldr r6, #380, However the value for ldr is "an 8-bit value that is multiplied by 4 and added to the value of the PC to form the memory address" (via ARMARM), so that the correct

splited patches and test cases mc-elf-thumbfunction-bit.diff: for 1 mc-elf-arm-backend-bl-blx-sign-bit.diff: for 2. mc-elf-thumb-bl-blx-relocation-table-entry.diff: for 3. mc-elf-cpu-xscale-attributes.diff: for 4. elf-thumbfunc.s: test case for 1 elf-thumbfunc-reloc.ll: test case for 2 and 3 elf-xscale-attribute.ll: test case for 4 On Fri, May 13, 2011 at 1:42 PM, Koan-Sin Tan <koansin.tan

Thank you for your help Tom you are totally right with the registers but the command you suggest also doesn't work. After some research I found the following thread on the mailing list: http://lists.llvm.org/pipermail/llvm-dev/2017-February/110086.html With your help and the information about the condition codes I was able to resolve the error:         BuildMI(BB, BB.end(), DL,

On 03/22/2018 09:29 AM, Julius Hiller via llvm-dev wrote: > Hello everyone, > > I'm working on a MachineFunctionPass that inserts a list of instructions into an Module so a later Pass can work on them. > To do so I load a dummy .ll file created from a main stub, create the needed function stubs (ModulePass), insert Blocks and create instructions using BuildMI. > I started with

Hi Koan, In general, this looks OK to me. Please split the patch into separate pieces, one for each issue you're addressing, though. From your description, it sounds like this should be 4 patches. That way we have a cleaner revision history in svn. -Jim On May 12, 2011, at 10:42 PM, Koan-Sin Tan wrote: > Hi, > > We are trying to use clang as a drop-in replacement for the gcc come

If I'm understanding what's going on in this test correctly, what's happening is: * ARMTargetLowering::LowerCall prefers indirect calls when a function is called at least 3 times in minsize * In thumb 1 (without -fno-omit-frame-pointer) we have effectively only 3 callee-saved registers (r4-r6) * The function has three arguments, so those three plus the register we need to hold the

Hi, Compiling attached test-case, which is reduced version of of uECC_shared_secret from tinycrypt library [1], with --target=arm-linux-gnueabi -march=armv6-m -Oz -S results in reloading of register holding function's address before every call to blx: ldr r3, .LCPI0_0 blx r3 mov r0, r6 mov r1, r5 mov r2, r4 ldr r3,

Hi, I have attached WIP patch for adding foldMemoryOperand to Thumb1InstrInfo. For the following case: void f(int x, int y, int z) { void bar(int, int, int); bar(x, y, z); bar(x, z, y); bar(y, x, z); bar(y, y, x); } it calls foldMemoryOperand twice, and thus converts two calls from blx to bl. callMI->dump() shows the function name "bar" correctly, however in generated

On 11-05-16 09:21 AM, Koan-Sin Tan wrote: > splited patches and test cases > > mc-elf-thumbfunction-bit.diff: for 1 > mc-elf-arm-backend-bl-blx-sign-bit.diff: for 2. > mc-elf-thumb-bl-blx-relocation-table-entry.diff: for 3. > mc-elf-cpu-xscale-attributes.diff: for 4. > > elf-thumbfunc.s: test case for 1 > elf-thumbfunc-reloc.ll: test case for 2 and 3 >

> Thanks for the review and checkin. Thanks for the patch! > Regarding elf-thumbfunc-reloc.ll, it seems to me that current ARMAsmParser > doesn't recognize "(PLT)", so something like "bl foo(PLT)" doesn't work > consequently. And I don't know how to write .s to test this without (PLT). NP. Can you just add that as a FIXME in elf-thumbfunc-reloc.ll?

Hi Craig, Thanks for the information. Can you point to the source that specifies tGPR to be R0 - R7? I tried to search in ARMInstrThumb.td but couldn’t find it. Thanks, - Jie On Apr 14, 2019, at 15:28, Craig Topper <craig.topper at gmail.com<mailto:craig.topper at gmail.com>> wrote: I believe there is probably a separate instruction in LLVM for thumb2 add. Probably starting with t2

On Wed, May 18, 2011 at 12:05 AM, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: >> Regarding elf-thumbfunc-reloc.ll, it seems to me that current ARMAsmParser >> doesn't recognize "(PLT)", so something like  "bl foo(PLT)" doesn't work >> consequently. And I don't know how to write .s to test this without (PLT). > > NP.

Hi, Simple question that I can't track down any notable discussion about, let alone an answer... Is it possible to define what the "default" nic and storage types are? I am deploying images out of cobbler using koan and all of them are running virtio wherever applicable, but this is not the default, and at present there is no way within koan or cobbler to define what type of

Hello everyone, I'm working on a MachineFunctionPass that inserts a list of instructions into an Module so a later Pass can work on them. To do so I load a dummy .ll file created from a main stub, create the needed function stubs (ModulePass), insert Blocks and create instructions using BuildMI. I started with branch instructions:     const TargetMachine &TM = MF.getTarget();

Using the koan command, a VM can essentially request that it be reprovisioned. Is there any way for a VM to request that it reboot from a snapshot taken with virsh? Thanks.. -- #ken B-)} Ken Coar, RHCE, RHCSA, Sanagendamgagwedweinini IT Engineering Tower, Red Hat/RDU "Millennium hand and shrimp!" -------------- next part -------------- A non-text attachment was scrubbed... Name: