search for: litpools

Why did you take out the constant island code for Arm 64? Just did not need it? On 02/21/2013 12:01 PM, Tim Northover wrote: > Hi Reed, > >> I'm wondering if there is already some mechanism where I can assign literals >> to the text section and get a label for where it has been stored. > > I think putting them in the text section is reasonably simple, though >

...inery and ARMConstantIslands is for fixing up out of range loads and so on so they can actually be used. My recent changes have been to fix Darwin CodeGen so that they're actually useful (previously we combined movw/movt pairs referring to the same global but not litpool ones, which meant that litpools actually took up more room), and to enable them in "-Oz" mode. It sounds like you're on an ELF platform, in which case (fingers crossed) you already get the combining unless you compile with "-fPIC". The "-Oz" change *should* just apply directly and be useful. Ple...

On Wed, 15 Apr 2020 at 03:36, John Brawn <John.Brawn at arm.com> wrote: > > > Could you please point out what am I doing wrong in the patch ? > > It's because you're getting the function name by doing > callee->getName().str().c_str() > The str() call generates a temporary copy of the name which ceases to exist outside of this expression > causing the

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

...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 because the code section (and any embedded litpools) need to be identical no matter where everything is loaded in memory. This is most of the point of .dylib files: the instructions only have to exist once in memory and can be shared. If the bytes would be different for each user that's not possible -- the linker spots places where that happens...

...om.arm.../IHI0044D_aaelf.pdf) specifies something called mapping symbols, which assemblers should insert to tell disassemblers what's actually needed. The idea is that a $a should be inserted at the start of each section of ARM code, $t before Thumb and $d before data (including these embedded litpools). In the above example, $a would be somewhere before the first ldr, $d at "special_lit_sym" and $a again at "past_literals". objdump will then use these to decide how to display a given address. If you dump the symbol table with "readelf -s" (objdump hides them on my...

I'm attempting to detect encoding bugs by comparing disassembly when using GCC's 'as' versus LLVM's integrated assembler. Generally this has gone very well, but one thing that adds a lot of noise is that .word marked as a R_ARM_ABS32 is disassembled as an instruction and not data. Please see the attached 'dump.diff' which was generated by diffing the "objdump -d

...iliar 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 because the code > section (and any embedded litpools) need to be identical no matter > where everything is loaded in memory. This is most of the point of > .dylib files: the instructions only have to exist once in memory and > can be shared. If the bytes would be different for each user that's > not possible -- the linker spots place...

Hi, All, I want to lower 64 Bits constant such as 'long' and 'double'. So I define them like this: def CONSTI64 : InstFOO<(outs GRWideRegs:$dst), (ins i64imm:$src), "const-long $dst, $src", [(set (i64 GRWideRegs:$dst), imm:$src)]>{ let isMoveImm = 1; } def CONSTF64 : InstFOO<(outs

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

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, 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};

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

...> specifies something called mapping symbols, which assemblers should > insert to tell disassemblers what's actually needed. > > The idea is that a $a should be inserted at the start of each section > of ARM code, $t before Thumb and $d before data (including these > embedded litpools). In the above example, $a would be somewhere before > the first ldr, $d at "special_lit_sym" and $a again at > "past_literals". objdump will then use these to decide how to display > a given address. > > If you dump the symbol table with "readelf -s" (...

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,