similar to: [RFC] [ARM] Execute only support

Today I updated to trunk the toolchain for my work developing on Cortex-M4F. I was super excited to see three commits by Tim Northover that actually attempt to improve the machine code generation for my target, or any ARM target for that matter (as opposed to other important work on compiler correctness or architectural elegance or formatting comment white-space, I mean). Is he alone or are

Hi Gary, On 3 December 2013 22:01, Gary Fuehrer <gfuehrer at defiant-tech.com> wrote: > The subject of two of his commits dealt with substituting MOVW/MOVT pairs > for an LDR and a lit-pool. Isn't this what MachineConstantPool and > ARMConstantIslandPass was all about? Both are essential components to using lit-pools: the MachineConstantPool is just LLVM's underlying

Hi folks, me again, So, I want to implement a simple optimization in a NEON case I've seen these days, most as a matter of exercise, but it also simplifies (just a bit) the code generated. The case is simple: uint32x2_t x, res; res = vceq_u32(x, vcreate_u32(0)); This will generate the following code: ; zero d16 vmov.i32 d16, #0x0 ; load a

Hi Ashi, > ld: illegal text-relocation to _data_table in table.o from foo in > use_table.o for architecture armv7 It looks like you're using iOS. I'm not familiar with the exact workings of that platform, but I think a similar message would occur in ELF-land. If iOS *is* comparable, your issue is that symbols in dynamically loaded objects can't (usually) be referenced directly

On Oct 14, 2013, at 3:27 AM, Zakk <zakk0610 at gmail.com> wrote: > Hi all, > I meet this problem when compiling the TREAM benchmark (http://www.cs.virginia.edu/stream/FTP/Code/) with enable-misched > > The small function will be scheduled as good code, but if opt inline this function, the inline part will be scheduled as bad code. A bug for this is welcome. Pretty soon, I’ll

Hi all, I meet this problem when compiling the TREAM benchmark ( http://www.cs.virginia.edu/stream/FTP/Code/) with enable-misched The small function will be scheduled as good code, but if opt inline this function, the inline part will be scheduled as bad code. so I rewrite a simple code as attached link (foo.c), and compiled with two different methods: *method A:* *$clang -O3 foo.c -static -S

> And be warned that the PC doesn't point at the next instruction when you use it like this - I believe you don't need to modify it at all if you swap the pop and the .long. Bernie, is it related to ARM pipeline? I'm interesting in this, is there any other additional information? On Fri, Mar 8, 2013 at 4:59 AM, Tim Northover <t.p.northover at gmail.com>wrote: > Hi Ashi,

Hi, Bernie, Thanks for your reply! However, I still have problem by following edk2's code, my test code is attached, what I want to do is build it as a dynamic lib. But I get error from ld: ld: illegal text-relocation to _data_table in table.o from foo in use_table.o for architecture armv7 Do you have any suggestion to solve this? Thanks! //==begin table.c== int data_table[] = {0xff, 0xff};

+llvmdev -llvmcommits On Fri, Nov 12, 2010 at 8:03 AM, Jim Grosbach <grosbach at apple.com> wrote: > Sorta. getBinaryCodeForInst() is auto-generated by tablegen, so shouldn't be modified directly. The target can register hooks for instruction operands for any special encoding needs, including registering fixups, using the EncoderMethod string. For an example, have a look at the

Hi I'm working on a POC adding Windows Phone (ARM) support to the ARM backend. I've encountered the following problem. Microsoft's COFF linker/loader supports a single relocation type ( IMAGE_REL_ARM_MOV32T) on continuous movw/movt Thumb2 instructions opposed to ELF and Mach-O which support relocation per instruction (one for movw and movt). I need to make sure that in case of

On Nov 12, 2010, at 7:23 AM, Renato Golin wrote: > Hi folks, me again, > > So, I want to implement a simple optimization in a NEON case I've seen > these days, most as a matter of exercise, but it also simplifies (just > a bit) the code generated. > > The case is simple: > > uint32x2_t x, res; > res = vceq_u32(x, vcreate_u32(0)); > > This

Hi Ashi, Your first LDR is a pseudoinstruction that is supported by some tools (gas and armasm, at least), but not by LLVM. Roughly speaking, it turns into a PC-relative load from a literal pool. To do what you're trying to achieve you can write your own literal pool in your assembly. You can see some examples of this sort of thing at

On Feb 17, 2011, at 10:35 PM, Вадим Марковцев wrote: > Hello everyone, > > I've added the "S" suffixed versions of ARM and Thumb2 instructions to tablegen. Those are, for example, "movs" or "muls". > Of course, some instructions have already had their twins, such as add/adds, and I leaved them untouched. Adding separate "s" instructions is

Hi Everyone, I'm working Chromium targeting Windows on ARM64 platform. As a part of this work I ran into an issue related to llvm in Swiftshader. Currently fixup_aarch64_movw relocation type is not supported for COFF ARM64 (AArch64WinCOFFObjectWriter). As far as I see, Microsoft hasn't defined indicator for this relocation type. I haven't seen documented anywhere. For AArch32

> How will these bundles interact with ARM codegen? The constant island pass in particular. > Hi Jim, This is a great question. >From the compiler's point of view, these bundles indeed pose a problem for the constant island pass. At this point for the NaCl platform we disable this pass, generating instructions like movt instead (NaCl requires at least v7 for ARM). However, as a

Hello everyone, I've added the "S" suffixed versions of ARM and Thumb2 instructions to tablegen. Those are, for example, "movs" or "muls". Of course, some instructions have already had their twins, such as add/adds, and I leaved them untouched. Besides, I propose the codegen optimization based on them, which removes the redundant comparison in patterns like orr

Hi everyone, happy new year. This note is to announce that support for PC relative reloc tags for movw/movt is nearing completion (hopefully <48hrs!). This work is is from Jan Voung, David Meyer and myself. Unfortunately, to test this change, we need to patch ARM/AsmParser to address http://llvm.org/bugs/show_bug.cgi?id=8721 Locally, we have hacked up a solution to 8721, but its not ideal

Hi Andy, Andrew Trick wrote: >> On Sep 23, 2016, at 7:50 AM, Christof Douma <Christof.Douma at arm.com <mailto:Christof.Douma at arm.com>> wrote: >> >> I can’t help to ask. Why not define a wrapping nsw instruction as UB, instead of “delayed UB” aka poison? I believe we >> have the notion of poison solely to ease the movement of instructions. In my example

>> Do the ARM usages include allowing a single pseudo-instruction to expand >> to multiple real instructions? For example, a movw/movt pair? If so, I’m >> *very* opposed to that part. > > > Why? For people writing assembly manually, having pseudo instructions to > encapsulate common patterns is very useful. Would it be acceptable for this pseudo-instruction to

Martin, Thanks for your suggestion. I look at these tests, try to make them work for COFF. Adam On 2019. 10. 02. 12:23, Martin Storsjö wrote: > On Wed, 2 Oct 2019, Adam Kallai wrote: > >> I'm working Chromium targeting Windows on ARM64 platform. As a part >> of this work I ran into an issue related to llvm in Swiftshader. >> >> Currently fixup_aarch64_movw