search for: constantislands

...get a label for where it has been stored. I think putting them in the text section is reasonably simple, though doesn't have a generic "pleasePutConstantsAfterFunctions()" call in LLVM. A good place to start would be the reverse of my recent patch to AArch64 which removed the entire ConstantIslands thing. It looks like the key points are creating a "CONSTPOOL_ENTRY" "instruction" which is emitted in the AsmPrinter. A relatively simple pass should be able to convert constpool entries as LLVM sees them into such instructions (see "doInitialPlacement"). Most of the...

> De : Joerg Sonnenberger [mailto:joerg at britannica.bec.de] > > Well, MCFixup is what a relocation is represented as internally. They get > resolved to a fixed value and replaced, if evaluateAsAbsolute is true. > Hi Joerg, Actually it fails to get resolved to a fixed value. When I compile to .o then objdump it I can see that a symbol holding the constant value was created in

I am working towards a more complete solution for large constants in mips 16 (ala Arm constant islands and such). That is part of why I'm busy expanding all macros being emitted in the mips 16 compiler (almost done). I'm wondering if there is a poor mans approach for large constants that can be done very simply that I can add just for now. Gcc mips 16 places them after the function

...to introduce space between > the > > beginning of the code and the jump table. > > It does look like the value in @llvm.arm.space is interpreted > incorrectly if it's bigger than INT_MAX, but that's well outside its > intended range and could inevitably be used to break ConstantIslands > (the longest ARM immediate branch is 26-bits; no indivisible entity in > .text can be bigger than that). It's probably an unrelated issue. > > Also, I know I said the backend should accept any size code, but 2GB > is definitely going to trigger more edge cases than average. &gt...

I have created a small ll file to reproduce the problem. I used the intrinsic function llvm.arm.space to introduce space between the beginning of the code and the jump table. If the first argument of llvm.arm.space is higher than INT_MAX ( *2147483647)*, then the bug is hit. Lower or equal to that value, it passes. It looks like a precision issue. Does this sound familiar to someone? ; ModuleID =

...1737). * `vec_vsx_ld` and `vec_vsx_st` intrinsics have been added for PowerPC. [r221767](http://reviews.llvm.org/rL221767). * PowerPC gained support for small-model PIC. [r221791](http://reviews.llvm.org/rL221791). * The llvm.arm.space intrinsic was added to make it easier to write tests for ARM ConstantIslands. [r221903](http://reviews.llvm.org/rL221903). ## Clang commits * The constant trickle of OpenMP patches continues. Codegen for threadprivate variables has been added. [r221663](http://reviews.llvm.org/rL221663). * Support for `__has_cpp_attribute` is now present. [r221991](http://reviews.llvm.o...

...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 machinery 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 mo...

...stored. > > I think putting them in the text section is reasonably simple, though > doesn't have a generic "pleasePutConstantsAfterFunctions()" call in > LLVM. > > A good place to start would be the reverse of my recent patch to > AArch64 which removed the entire ConstantIslands thing. It looks like > the key points are creating a "CONSTPOOL_ENTRY" "instruction" which is > emitted in the AsmPrinter. A relatively simple pass should be able to > convert constpool entries as LLVM sees them into such instructions > (see "doInitialPlacement&...

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