similar to: [LLVMdev] Instruction dependency in ARM backend

+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 planning to implement "execute only" support in the ARM code generator. This basically means that the compiler will not generate data access to the generated code sections (e.g. data and code are strictly separated into different sections). Outline: - Add the subtarget feature/attribute "execute-only" to the ARM code generator to enable the feature.

>> 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

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 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 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

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

> This has several problems for direct object emitting Why? Just expand these pseudos before asm printing and you're done. This is the approach used by other targets. Check e.g. ARM backend for handling movw + movt pair of instructions. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

On Dec 6, 2012, at 2:45 PM, Eli Bendersky <eliben at google.com> wrote: >> 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

The llvm compiler can now generated movt/movw instructions to create 32-bit constants. Those new instructions use new relocations. Mach-o uses different numbering for relocations than ELF does. For mach-o, ARM_RELOC_PAIR=1 and ARM_RELOC_HALF=8. You need a newer linker that understands the new relocations. -Nick On Feb 20, 2012, at 5:20 AM, Harel Cain wrote: > Hi all, > > I'm

On 10 January 2011 22:59, Jason Kim <jasonwkim at google.com> wrote: > 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. Hi Jason, Happy new year! That seems a long patch... with many changes... can't

-llvmcommits On Mon, Jan 10, 2011 at 3:21 PM, Renato Golin <renato.golin at arm.com> wrote: > Btw, I know this is for ELF printing, but can the same infrastructure > you're using to print the hi/lo be used to print relocation in Asm > output? Or is this a completely separate subject? Hi Renato, If I am understanding you correctly, then the answer is no, because .s output

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

When the IR specifies a 32 bit load can it be changed to a narrower load? What if the load is from memory (e.g. a peripheral) that only supports 32-bit access? Consider the following IR: ---- target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:32" target triple = "thumbv7m-unknown-unknown" @f = external global i32 define zeroext i8 @bar() nounwind { L.0:

This Pattern class says it's possible but seems just to not work or maybe I'm using it incorrectly. Probably I will go and fix it when I'm done with mips16. ________________________________________ From: Hal Finkel [hfinkel at anl.gov] Sent: Sunday, September 16, 2012 10:59 AM To: Anton Korobeynikov Cc: Kotler, Reed; LLVM-Dev ‎[llvmdev at cs.uiuc.edu]‎ Subject: Re: [LLVMdev] Pattern

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

Thanks very much, Renato! I looked into the regressions, there're many cases have similar context as the case I mentioned but N just has only one use. In this case, the canonicalisation won't make it more profitable, will only prevent the possible folding or make the sequence is not expected. The regressions be eliminated, after I limit the expanding to not "N->hasOneUse()".

On Oct 25, 2013, at 5:22 PM, Sean Silva <chisophugis at gmail.com> wrote: > I’m not sure macros are a good analogy, but there are other pseudo-instructions that we’re not always able to reconstruct in disassembled code back to how the user wrote them. Or if we do, it’s purely via heuristic methods. I don’t see this as a big issue. I agree. These pseudo instructions seem like pure

On Sun, 16 Sep 2012 21:33:26 +0400 Anton Korobeynikov <anton at korobeynikov.info> wrote: > > This has several problems for direct object emitting > Why? Just expand these pseudos before asm printing and you're done. > This is the approach used by other targets. Check e.g. ARM backend for > handling movw + movt pair of instructions. I think that *if* it were possible to

> 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