similar to: [LLVMdev] proposed patch to make mips16 exception handling work

I thought of a simpler way to do this which is no more of a hack than the way labels are noramally output. Create an EmitDebugLabel and then in MCAsminfo, add another variable for the suffix for debug labels which can by default be just ":". Then for Mips I can change it to "=." On 11/03/2012 01:40 PM, Reed Kotler wrote: > I'm working on a patch for this problem

I'm working on a patch for this problem for mips16; unfortunately it's a target independent patch. I'm not sure the best nomenclature for this. In the gcc mips16 patch they call "xxx=." a debug label. The other terminology they use is byte pointer vs ISA-encoded address (ISA-encoded meaning this one bit in the case of mips16 ISA). I'm planning to add a virtual method

mips16 has some unusual requirements for label symbols in .s. I think that arm thumb has the same issue but have not located yet how this is handled. When you have a label of an instruction in mips16, when you reference the label, the linker adds a 1 to the address. When you call an odd numbered address, the procesor switches to mips16 mode and when you call an even numbered address it

Okay to push this change? On 07/23/2013 05:17 PM, reed kotler wrote: > Hi Daniel, > > In this case we are not using lnt under Qemu user mode for benchmarking; > just as a way to run test-suite to test whether the code is correct. > > Qemu user mode emulates target instructions, but when it gets a Unix > Kernel trap, it uses the host to emulate those. > > For example,

Hi Jim, There is no "target independent" code in these patches. It's all Mips specific. There is something I'm proposing for AP/NO_APP wrappers but that will just make the stubs look nicer (without the clutter of those wrappers). That is purely a cosmetic issue of the .s files being produced. The discussion has moved back to the main thread so I'll continue there.

On Fri, Nov 02, 2012 at 07:53:41PM -0700, reed kotler wrote: > Basically, labels that are not landing pad symbols that are inserted > for exception handling > and dwarf purposes, must declared : > > $mysym = . > > as opposed to: > > $mysym: Can't you use $mysym +/- 1 in the landing pad reference to work this idiosyncracy? Joerg

So the switching between mips16 and mips32 on a per function basis seems to basically be working except that asm printer has some kind of issue here. I'm debugging that now. I get this: lc: /home/rkotler/workspace/llvmpb6/include/llvm/MC/MCStreamer.h:224: void llvm::MCStreamer::SwitchSection(const llvm::MCSection*): Assertion `Section && "Cannot switch to a null

So I have dual mode 16/32 compilation on a per function basis working. I need to clean up some things and then will push the change. I managed to do everything without needing to change anything in target independent code thus far. It was a fun puzzle to solve as to how to do this using only the given APIs. As for the BasicTransformInfoPassass, for this dual mode I'm using

On 04/01/2013 12:31 PM, Chandler Carruth wrote: > On Thu, Mar 28, 2013 at 12:22 PM, Nadav Rotem <nrotem at apple.com > <mailto:nrotem at apple.com>> wrote: > > IMHO the right way to handle target function attributes is to > re-initialize the target machine and TTI for every function (if > the attributes changed). Do you have another solution in mind ?

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

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

For example: /home/rkotler/llvm/install/bin/llc -mcpu=mips16 hf16_2.ll -march=mipsel -relocation-model=pic -o hf16_2.s -O3 -mips16-hard-float -soft-float On 01/04/2013 07:45 PM, Eli Friedman wrote: > On Fri, Jan 4, 2013 at 6:28 PM, reed kotler <rkotler at mips.com> wrote: >> On 01/04/2013 06:08 PM, Eli Friedman wrote: >>> On Fri, Jan 4, 2013 at 4:08 PM, reed kotler

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

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

I'm working on the mips16. Mips16 is a mode of the Mips32 (or Mips64) processor. For the most part, it is a compressed form of the MIPS32 instruction set, though not all instructions are supported. Most of the same opcodes and formats are present though sometimes with some restriction. (The micro mips architecture is a true 16 bit compressed form of MIps32 though also with some

On Fri, Jan 4, 2013 at 4:08 PM, reed kotler <rkotler at mips.com> wrote: > I'm working on mips16 hard float which at a first approximation is just soft > float but calls different library routines. Those different library routines > are just an implementation (in mips32 mode) of soft float using mips32 > hardware instructions. This part is already done. (mips16 mode has no

On Fri, Jan 20, 2012 at 1:59 PM, reed kotler <rkotler at mips.com> wrote: > We are starting to look at the mips16 and micro mips ports. > > There are various design issues that people may have some good input on. > Especially in how to structure the TD files and other optimizer issues. > > Mips16 is sort of like thumb and Micro Mips like thumb2 as far as I > understand.

i'm trying to formulate the optimal way to do comparison testing for mips 16. on mips32 there are no condition codes. you can test a<b and place the result in a register in mip32. on mips16 you can do the same, however, the register is always T8==24. T8 is not directly accessible by most mips16 instructions, but can be directly moved to a generally accessible mips16 register, and can

On Jan 24, 2012, at 1:46 AM, Reed Kotler wrote: > Mips16 is a mode of the Mips32 (or Mips64) processor. For the most part, > it is a compressed form of the MIPS32 instruction set, though not all > instructions are supported. Most of the same opcodes and formats are > present though sometimes with some restriction. (The micro mips > architecture is a true 16 bit compressed form