similar to: [LLVMdev] Mips16 constant islands port of ARM passing test-suite now

Is there any code in test/Codegen/ARM for constant islands testing? I could not find any. TIA. Reed

I have to look at some issues in static but the initial port is pic and all of test-suite now passes. Even the crazy mips16 hard-float and interoperability with mips32 is working in test-suite. People that have experience with this in gcc mips16 can attest to the complexity there. More testing and other work but at least the base port is there. Reed

Currently the ARM port does constant islands on a per function basis. I'm aware of at least one other port that does this kind of optimization on the mc layer. To do such long/short jump and load optimizations, you don't need anything about registers or basic blocks. So it seems this would be better because then you can pool things on a per module basis. In the case of Mips16, the

ARM absolutely needs to know about control flow in that pass. -Jim On Oct 11, 2013, at 2:16 PM, reed kotler <rkotler at mips.com> wrote: > Currently the ARM port does constant islands on a per function basis. > > I'm aware of at least one other port that does this kind of optimization on the mc layer. > > To do such long/short jump and load optimizations, you

On Nov 18, 2013, at 3:49 PM, reed kotler <rkotler at mips.com> wrote: > I don't know ARM hardly at all but... > > This comment does not seem to match the code. > Or maybe tBfar is a BL? What does the definition of tBfar say? > > Also, how does this work if the destination is greater than 2**21? > It doesn’t. IIRC, that’s under the category of “if people start

On 11/18/2013 06:34 PM, Jim Grosbach wrote: > On Nov 18, 2013, at 3:49 PM, reed kotler <rkotler at mips.com> wrote: > >> I don't know ARM hardly at all but... >> >> This comment does not seem to match the code. >> Or maybe tBfar is a BL? > What does the definition of tBfar say? Okay.. but // Far jump // Just a pseudo for a tBL instruction. Needed

I'm wondering if anyone cares to weigh in on the "goodness" of the arm constant island pass. Also, regarding any "i wish we had done xxxx differently".... I'm planning to port it for Mips16 but also have the option to roll my own. I'm studying the pass in detail right now. Tia. Reed

I don't know ARM hardly at all but... This comment does not seem to match the code. Or maybe tBfar is a BL? Also, how does this work if the destination is greater than 2**21? /// fixupUnconditionalBr - Fix up an unconditional branch whose destination is /// too far away to fit in its displacement field. If the LR register has been /// spilled in the epilogue, then we can use BL to

I don't think that anybody is working on mips16 except for me but just in case, I wanted to outline some work that is going on so that nobody else duplicates it: 1) Fix exception handling for Mips 16. Patch already pushed for review. 2) Finish up handling of large frames. 90% of code done and being tested. One more patch is needed. 3) Hard float. (mips16 has no floating point instructions

I hope I can wrap it up soon. After my weekend putbacks, I'm down to 0 failures in Single-source and 5 failures in multi-source but have not investigated yet. Sometimes they are gcc mips16 (which is used for comparison results) or other build issues and not really llvm failures. Mips16 has many nutty problems, especially regards floating point, register set, exception handling, and

ARM begins by putting constants into a basic block following the last one in the function. In some cases, those constants would be better put in a basic block that is before the beginning of the function. Is it possible to create a basic block that is before the first executable instruction of the function?

I'm starting to look more seriously at the problem of being able to running TargetLowering on a per function basis. In particular, I want to be able to compile functions as mips16 or mips32 , mixing them within a single compilation unit. It would be great if some more experienced people in this overall structure of the compiler would give their 2c because I'd hate to spend a lot of

Dear List, This is Elaine, a postgraduate studying in bird distributions in East Asia. I want to calculate Simpson dissimilarity index, based on a presence/absence matrix of bird species in islands in East Asia. (matrix row: 36 islands/matrix column: species ID) (R package vegan to make NMDS and R package betapart) In most papers using vegan for NMDS and betapart for dissimilarity

Scotland is the second feature in the UK data, so get it and split this one MULTIPOLYGON feature into individual POLYGONS scot = st_cast(the_uk$geometry[2],"POLYGON") # which is the largest polygon? which.max(st_area(scot)) [1] 1 # the first one. ok... plot(scot[[1]]) # mainland # add the rest of the islands for context, in grey, maybe to show they're outside our study area:

Right now inline assembler just passes through to the assembler if there is no direct object emitter. If there is a direct object emitter, it gets processed in Asm parser and MC instructions are produced. I propose that the initial parsing happen very early and the inline assembly code be replaced with a sequence of MachineInstructions in the basic block where it occurs. Then code like

On Aug 18, 2010, at 11:37 AMPDT, Pawel Wodnicki wrote: > On 8/18/2010 12:39 PM, Dale Johannesen wrote: >> I can look at this, but you'll need to send the .bc file. Please >> open a PR? > > I would do it but I am in a bit of a pickle as the .bc is from > propriety code and > I can not post it. Can't help much then. You might look into obfuscating the

1. mips16 instructions (except for move) have a different encoding from normal mips32 instructions for two registers. however in the move register 2 operand instruction, one register takes the mips16 encoding and the other the mips32 encoding (so that gives mips16 access to the full register set). how does one deal with multiple encodings of the same register? can you change it on an

Mips16 mode has no floating point instructions. (Remember that mips16 is just an alternate decoder mode for the processor, mips32 or mips64 is the base processor). Currently with gcc for mips16, when there is floating point it generates a function call to emulate each floating point instruction. For mips 16 in llvm I want to just compile any function that has floating point, in mips32 mode.

I added one method which clears the list of register classes. Then there is a change to mips16 code which simulates switching from mips32 to mips16 mode in the same module. It seems to work fine in that I can run this version of llvm for mips16 and it works identical to the one without this code. Beyond the "make check" I have run test-suite against this version. We could just

Usually we do all the accessing of stack variables via the SP register. When the stack size is dynamic we need a frame pointer, FP. There is a traditional FP register for MIPS, but FP is not a mips16 register so in general it has little use for mips16 because you can't directly address it except in the move instruction when moving from/to mips16 to mips32 register. There are several ways